Would be nice to have the support corner again to talk with the WRC folks.
- Log in to post comments
Would be nice to have the support corner again to talk with the WRC folks.
Benefits? Healthcare? comp band? remote possible?
while you can (clumsily) script terminal sessions, it might be easier to connect to your db via odbc and use isql, or maybe even use the newer python capabilities to get your data out via a python script
Have a look at the Store and StoreFiles methods: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic…
especially when there are cases where the first few people per problem took hours for the split time and then there's a lot of people with sub 1 minute times. I won't go through the effort of looking through their code to see if they actually only had to do a one line change to solve the second part. i would call that suspicious.
a really good analysis is also to look at the split times of everybody (=how long between submitting part 1 and part 2). the api gives us the data.
you weren't the only one :)
Please note that 12 characters is very much not a secure password, regardless of the characterset. https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
any other restrictions on the code we should be aware of?
How are you protected in this setup against two instances coming up and writing into the same db? I.e. due to flaky network?
The link doesn't work. Also note my other response, there is actually an API for that already.
For next time, this might be helpfull:
https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic…
In windows it just triggers the service restart (which you can also do from the service.msc terminal), in linux it restarts the daemon.
Neither of which will be helpful if apache is properly frozen, in that case you'll have to kill it manually first.
I think this " OAuth authorization is much more robust and recommended for production use." should be emphasized a bit more :) This might lead to people getting the idea that rolling their own encryption related code is an acceptable idea :/
typo: zuauthenticat -> zauthenticate
You will benefit much more directly by letting your instance have that extra memory directly and not via that added extra step of creating that virtual drive. Give your instance more global buffers. Also from the sounds of it you might want to look at your queries and associated query plans in a bit more detail. You should get in touch with the WRC for that, they're great at sorting out why queries run slow ( you might want to reach out to car-part first, maybe they've fixed some of the queries)
It's a proprietary compiler compiling into a proprietary bytecode. So no llvm support, and certainly no in depth documentation of it ;)
Even just doing a read access is significantly slower with the %DynamicArray types. I ran into that during the Advent of Code puzzles and had to fall back to $LB lists and arrays. consider a simple loop to go through 100k items:
Class fkh2019.Bench Extends %RegisteredObject
{
ClassMethod listtest()
{
#; let's build a long list
s mylist=""
for i=1:1:100000{
s mylist=mylist_$LB(i)
}
s start=$P($ZTS,",",2)
Set P=0
While $LISTNEXT(mylist,P,value) {
s disgard=value
}
s end=$P($ZTS,",",2)
return end-start
}
ClassMethod dyntest()
{
#; let's build a long list
s mylist=[]
for i=1:1:100000{
d mylist.%Push(i)
}
s start=$P($ZTS,",",2)
Set it=mylist.%GetIterator()
While it.%GetNext(.key,.value) {
s disgard=value
}
s end=$P($ZTS,",",2)
return end-start
}
ClassMethod runtests()
{
s t1=..listtest()
s t2=..dyntest()
w "list access took ",t1, " seconds",!
w "dyn array access took ",t2, " seconds",!
}
}
The %DynamicArray takes about 15x longer:
IRISAPP>d ##class(fkh2019.Bench).runtests()
list access took .005273 seconds
dyn array access took .082946 seconds
Thanks, it was a lot of fun! Good coding everybody and a happy new year to you all!
Anything using process memory usually falls over really quick as soon as you try and start using it for real use cases. Even increasing bbsiz is only a temporary band-aid in most cases.
It's a graph library that allows me to create a generic graph. the shortestPath method uses A* (https://en.wikipedia.org/wiki/A*_search_algorithm) to find the shortest path connecting two nodes in the graph. This is reusable in all of the 'find a path through a maze' kind of puzzles. The lack of generalized libraries/tools is the biggest drawback in COS. For example Day20, part1: https://github.com/kazamatzuri/AoC/blob/1387289dbcacfa2d7dd62906e873c074fb32e689/aoc-cos-container/src/cls/fkh2019/Day20.cls#L133
k ^grid,^ports,^portals
d ..parseInitial()
d ..buildGraph()
d ..findPortals()
d ..linkPortals()
s entry=$LG(^portals("AA"),1)
s exit=$LG(^portals("ZZ"),1)
zw entry
w " -> ",!
zw exit
s path=..graph.shortestPath(entry,exit)
s length=$LL(..graph.shortestPath(entry,exit))-1
return length
had the same problem for 22 :/ I'm not aware of any big-num library for Iris. Probably because it's not really language used for numerical stuff.
day 18 takes quite long: https://github.com/kazamatzuri/AoC/blob/master/aoc-cos-container/src/cls/fkh2019/Day18.cls
Especially part1, part2 finishes quicker since it's 4 much smaller mazes. I'm still trying to improve it a bit (you have to adjust your memory settings to even work at all, otherwise you're getting
this one is actually the more helpful one: https://github.com/kazamatzuri/AoC/blob/master/aoc-cos-container/src/cl…
Good game :) I enjoyed the competition ;) Happy Holidays!
I also used a grid to store where the wires go, avoids the whole maxstring problem:https://github.com/kazamatzuri/AoC/blob/dd5eb40ca5b828f35953c196668dfe68618bec63/aoc-cos-container/src/cls/fkh2019/Day3.cls#L55
seems you're right. considering that i'm running with a 256gb assigned to docker anyways, I didn't expect that... oh well. tx for the hint :)
probably a mac problem ... I wonder how much those are being tested ;)
I'm running this version:
```
docker --version
Docker version 19.03.5, build 633a0ea
```
Interesting, that also blows up. different error though:
docker container run -it -p 51773:51773 -p 52773:52773 -p 5001:5001 -p 5000:5000 --name rcc2 --rm store/intersystems/iris-community:2019.3.0.309.0
[WARNING] No init process detected! This container may accumulate zombie processes if run for a long time. Consider using "docker create --init ..." or equivalent.
[INFO] Starting InterSystems IRIS instance IRIS...
[INFO] Starting Control Process
Automatically configuring buffers
Allocated 956MB shared memory: 744MB global buffers, 35MB routine buffers
WIJ directory locked - System not started
Starting IRIS
Startup aborted.
Startup error. See messages.log for more information.
Call InterSystems Technical Support if you need assistance.
[ERROR] sh: echo: I/O error
sh: echo: I/O error
[ERROR] Command "iris start IRIS quietly" exited with status 256
12/01/19-19:24:12:522 (367) 0 [Generic.Event] Automatically configuring buffers
[ERROR] Possible causes:
[ERROR] - InterSystems IRIS was not installed successfully
[ERROR] - Invalid InterSystems IRIS instance name
[ERROR] - Insufficient privilege to start InterSystems IRIS (proc not in InterSystems IRIS group?)
[FATAL] Error starting InterSystems IRIS
keep in mind, pruning the images doesn't actually make the docker image (Docker.raw) shrink again. To achieve that you'll have to 'reset docker' (which will recreate that image)
Looks like a nice wrapper around https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon ?
I would suggest it makes much more sense to do logging to globals that are mapped into a DB that isn't being journaled in the first place. That way you don't have to add additional complexity of suspending a transaction (which is a great source for bugs...) Thanks, Fab