November 2014 - Pharo-dev - lists.pharo.org

SandstoneDB questions

by J.F. Rick

I'm starting to use SandstoneDB for a project (seems pretty cool) and I had two questions: (1) I noticed that the commit: instance method discussed in the documentation does not exist. Has it been deprecated? There is a commit: class method but it seems like instance functionality. (2) It seems like Sandstone does keep versions. Is there a way I can retrieve old versions? I can't seem to find an API for that. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Nov. 4, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a Ã©crit : > Alain > > which nativeboost chapter :)? > Could you propose a paragraph so that we cover the problem you faced? > > Stef > > On 4/11/14 00:44, Alain Rastoul wrote: >> Hi Igor, >> >> Thank you for your answer, it worked perfectly >> Looks like I overlooked the nativeboost chapter >> .. 10 timesRepeatAfterMe: [self rtfm ] . >> And my suggestion about testing nil was stupid, much better to fail soon. >> ... I am an ass on this one... >> >> However, I am struggling on another point you already answered in the >> past >> in the mailing list to a guy who wanted to use socket.io : >> (http://forum.world.st/socket-io-td3891592.html#a3893031) >> "Sockets in Pharo are not blocking the whole VM. >> What they block is the process which working with concrete socket. But >> other processes can still run, while >> one waiting data / even from single socket. " >> on windows, zmq socket receive is blocking, on linux, not blocking >> (hence not working). >> As zmq is doing is IO on another thread, I guess there is some side >> effect of >> socket receive timeout settings somewhere (in the plugin ?) - just a >> guess... >> Getting socket options shows no difference, but I don't know how it is >> done on the vm >> side with regards to threads and if the socket is the same (zmq socket >> is not the tcp socket)... >> And on linux, the equivalent C program of to the smalltalk version >> blocks as expected. >> >> I a mperplexified ... >> may be I should look at vm and plugin code (VMMaker package IIRC) ? >> Do you have another advice ? >> >> Thanks you >> >> Alain >> Le 03/11/2014 02:12, Igor Stasenko a Ã©crit : >>> NBExternalArray instances cannot be passed directly to functions >>> expecting pointers. >>> >>> use 'myarray address' for arguments. >>> >>> On 3 November 2014 00:20, Alain Rastoul >>> <alf.mmm.cat(a)gmail.com >>> <mailto:alf.mmm.cat@gmail.com>> wrote: >>> >>> Hi, >>> >>> I have a problem with a nativeboost call, but I don't see what I do >>> wrong. >>> >>> library function prototype is: >>> int zmq_getsockopt (void *socket, int option_name, void >>> *option_value, size_t *option_len); >>> >>> my calling method in pharo is: >>> zmq_getsockopt: socket option_name: option_name option_value: >>> option_value option_len: option_len >>> <primitive: #primitiveNativeCall module: #NativeBoostPlugin >>> error: errorCode> >>> ^self nbCall: #(int zmq_getsockopt (void *socket, int >>> option_name, void * option_value, size_t* option_len) ) >>> >>> when I call it with >>> ... >>> optionValue := (NBExternalArray ofType: 'int') externalNew: 1. >>> optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. >>> [ optionValue at: 1 put: 0 . >>> optionLen at: 1 put: (NBExternalType sizeOf: 'int') . >>> rc := self zmq_getsockopt: socket option_name: option_name >>> option_value: optionValue >>> option_len: optionLen . >>> value := optionValue at: 1 . >>> ] ensure: [ optionValue free. >>> optionLen free ]. >>> ... >>> I allways get an exception: "error during FFI call : nil" >>> >>> >>> After stepping in NBFFICallout generation, I found something >>> strange, the code >>> generation seems not to be called because lastError stays at nil ? >>> >>> handleFailureIn: aContext nativeCode: aBlock >>> lastError := self getErrorFrom: aContext lastError: >>> NativeBoost lastError. >>> >>> >>getErrorFrom: aContext lastError: errorCode >>> ... checks pragmas etc >>> >>getErrorFrom: aContext lastError: errorCode >>> ... lastError := aContext tempAt: method >>> numTemps. >>> => lastError = nil ??? shouldn't be >>> ErrNoNativeCodeInMethod ? >>> "install native code and retry the send" >>> lastError = ErrNoNativeCodeInMethod >>> ifTrue: [ ^ self generateCode: aBlock andRetry: >>> aContext ]. >>> never gets called ... >>> >>> "ok, we're out of options, signal an error here" >>> ^ self signalError: lastError >>> >>> Could it be because I use this image on windows and unix ? >>> Or because I had an exception at prototype parsing the first time >>> because I forgot a ; at the end of the prototype ? >>> >>> Is my prototype correct or is it the origin of the error ? >>> Is there a way to reset the lastError (aContext tempAt: method >>> numTemps) ? >>> I will try to reset it in debugger but may be there is a cleaner >>> way ? >>> would it be ok to change the test in handleFailure to >>> (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? >>> (I can open a bug in this case ) >>> >>> Any idea or comment is welcome >>> Thanks in advance >>> >>> Alain >>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >> >> >> >> > > >

Nov. 4, 2014

Re: [Pharo-dev] fixing 'format on display' and 'format on accept'

by Paul DeBruicker

Slice is in the Pharo30Inbox https://pharo.fogbugz.com/f/cases/14387/ressurrect-format-on-accept-and-for… It uses the settings browser as described below and auto-formats methods (on display or accept or both) in Nautilus and the senders/implementors browser. Paul DeBruicker wrote > Hi - > > I'm going to get 'format on display' and 'format on accept' working in > Nautilus. In Pharo 3 in the settings browser under 'code browsing' there > is a 'pretty print' check box. As far as I can tell it doesn't affect > code displaying at all in Nautilus. > > > Is it OK to repurpose that checkbox as a control for 'format on display' > and to also add a check box right there for 'format on accept' ? If not > what would be better? > > > Thanks > > Paul -- View this message in context: http://forum.world.st/fixing-format-on-display-and-format-on-accept-tp47883… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 4, 2014

Re: [Pharo-dev] LRUCache for high latency stuff

by Thierry Goubier

2014-11-04 14:33 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Thierry, > > I made a prototype implementation, would this be helpful ? > > LRUCache>>#at: key put: value > "Populate the receiver by putting value under key. > This operation is neither considered a hit or a miss. > If key is already present, replace it. Return value" > > ^ self critical: [ > (keyIndex associationAt: key ifAbsent: [ nil ]) > ifNil: [ | newAssociation link | > newAssociation := self newAssociationKey: key value: value. > link := lruList addLast: newAssociation. > keyIndex at: key put: link ] > ifNotNil: [ :existingAssociation | | link | > link := existingAssociation value. > weight remove: link value value. > link value value: value. > self promote: link ]. > self addWeight: value. > value ] > > (#newAssociationKey:value: is new, you can replace it with key->value) > Thanks, yet, that would fit. I'll make a try once the code is released; I'd be interested to have your comments on how to handle the cache. Release should happen in a few days, I hope. Thierry > Then you can do: > > testPopulate > | cache | > cache := self newCache. > cache factory: [ self fail ]. > cache at: #foo put: -1. > cache at: #bar put: 200. > cache at: #foo put: 100. > self assert: cache size equals: 2. > self assert: cache totalWeight equals: 2. > self assert: cache hits isZero. > self assert: cache misses isZero. > self assert: (cache at: #foo) equals: 100. > self assert: (cache at: #bar) equals: 200. > cache validateInvariantWith: self > > For Norbert I did a little change that allows you to subclass either > LRUCache or TTLCache and customise the Associations being used as well as > the stale testing. He wanted to have entry specific TTLs, not just one > value for the whole cache. Maybe that could also help you. > > The other question about HTTP client behaviour: I don't know how many > requests you could run parallel, 10s maybe 100s. I have it somewhere using > a custom limited resource pool, but when the pool is empty (all workers > active), clients wait. In my use case, it was all synchronous. > > If you like the #at:put: I could move it into the image. > > Sven > > > On 03 Nov 2014, at 23:14, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Sven, > > > > 2014-11-03 22:52 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Thierry, > > > > > On 31 Oct 2014, at 14:10, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > > > Hi all, > > > > > > I tried to use LRUCache for some application of mine with a two > stages, over-the-internet data requests, and I couldn't find a way of using > it. > > > > > > My use case was: > > > - retrieve some data with high latency (over 10 seconds) > > > - in a interactive application, where I need to be able to continue > while the data is being loaded. > > > > > > So I designed it in two stages: > > > - Have a cache > > > - if the data isn't in the cache > > > -- trigger a load with a fork > > > -- put some temporary data in the cache (something which says loading) > > > -- continue > > > - When the data load is terminated > > > -- replace the cached temporary data with the final version. > > > > > > The thing is that I couldn't do the last one with the LRUCache (there > is not at:put:, only a at:ifAbsentPut: []). Did I miss something? > > > > > > Thierry > > > > Relevant question and a rather special use case I would say. > > > > The API of AbstractCache and its subclasses is minimal by design. It > certainly does not contain everything that Dictionary has. > > > > A cache delivers values based on keys. The ifAbsent: block is similar to > the factory: block, it implements getting the value. Either you hit the > cache or you miss it and it gets loaded. Entries drop off either because > there are too many in some metric (LRUCache) or because they expire > (TTLCache). > > > > Now, #at:put: is like a replace, is it a hit or a miss ? Or neither ? > > > > It would be a replace, and neither a hit nor a miss. > > > > > > You could implement it with a #removeKey: and and #at:ifAbsent: - modulo > some concurrent access problems. > > > > I do those operations under a mutex, otherwise the system becomes > incoherent :) > > > > > > Maybe we should add it (I guess it could be useful to fill a cold cache > as well) - but I am not totally convinced. > > > > Now, your use case is a bit odd and dangerous. You spawn a > thread/process for each miss, there could be a large number of them - do > you want that ? Will the value always/still be needed when it arrives ? > > > > A non needed value (to late value) will be discarded almost immediately, > so this is not an issue. The number of threads may be high, yes, but it > stays apparently within reasonable limits (how many Zn requests one can do > simultaneously from Pharo? Is there any throttling?). > > > > > > One way to implement your use case would be to encapsulate your special > behaviour (the delayed loading) in the value itself (since you have the two > cases/states exposed), no ? > > > > Yes. This is more or less what I implemented, but without merging them > in a single object. > > > > This makes using the LRUCache as is, but is no better than the previous > approach about the number of threads in flight (those could be solved by a > sharedQueue and a few loading processes feeding themselves out of the > shared queue). > > > > Now I know how to use the LRUCache, but I think my use case is in a way > too simple for its features (no real TTL, LRU only works if the cache size > is over a certain threshold and that threshold isn't static). > > > > Thanks, > > > > Thierry > > > > Sven > > >

Nov. 4, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

oups, Dragon-ZeroMQ Dragon is my personal debug_log_filler DragonMQ sounds well too :) Le 04/11/2014 19:48, Alain Rastoul a Ã©crit : > Those experiments are on smalltalkhub under DragonMQ with public access, > a there_be_dragon_here debuglog filler for now (will probably > be renamed), > at the stage of a raw binding and basic experiments to become used > to zeromq, but at some point if it works well, it should ends up > in a wrapper plus some object oriented api on top of it. > > Le 04/11/2014 10:45, stepharo a Ã©crit : >> >>> Hi Alain, >>> >>> This is nice that you are working on a zmq binding for Pharo. >>> Is it public and on Sthub? >> >> +1 >> >> >> >> > > > >

Nov. 4, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Those experiments are on smalltalkhub under DragonMQ with public access, a there_be_dragon_here debuglog filler for now (will probably be renamed), at the stage of a raw binding and basic experiments to become used to zeromq, but at some point if it works well, it should ends up in a wrapper plus some object oriented api on top of it. Le 04/11/2014 10:45, stepharo a Ã©crit : > >> Hi Alain, >> >> This is nice that you are working on a zmq binding for Pharo. >> Is it public and on Sthub? > > +1 > > > >

Nov. 4, 2014

Re: [Pharo-dev] NAtiveBoost error

by Alain Rastoul

Le 04/11/2014 15:30, Igor Stasenko a Ã©crit : > > Do you create socket via zeromq library, do sockets managed through it? > yes > To make sockets to not block the VM, just using a nice library is not > enough: you must wire the socket events with VM process scheduling logic > through signaling the semaphores etc.. Else you must always use > non-blocking calls in C library. yes, this is done by zeromq, and one can specify blocking or non blocking socket option. By default (according to zeromq api) it should be blocking but it is not, I do not specify non blocking, but it is not blocking. > > Well, parallel computing is broad area.. with zillions goals and solutions. > The setup you described is not what i wanted to achieve with Hydra. Yes, I know, I know that you know, and now you know that I know that ... :) I made experiments with hydra in the past, I liked the idea very much. For now, personal circumstances allows me to have much more time to work on what interests me (still not enough but more than in the past) > Running multiple instances of same VM ~= running single instance of VM > which can manage multiple native threads. But sure thing you can > achieve similar results using both approaches. The difference is in how > fine grained your control over consumed resources, namely memory and CPU. > Working (more helping) on heavy load performance benchmarks on a very different platform (IIS, dotNet, MsSql), I got convinced that multiple single threaded programs could achieve at least the same or a higher throughput than the (even well written) single multi-threaded equivalent with a good nolocking behavior, less synchronisation and delays (semaphores, locks, critical sections), less cpu false sharing and cache invalidation... Regards, Alain > > > -- > Best regards, > Igor Stasenko.

Nov. 4, 2014

Re: [Pharo-dev] Dealing with very large files

by Alexandre Bergel

Ok! Cool! Thanks you guys for your answer! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 4, 2014, at 12:36 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Alexandre, > > On Nov 4, 2014, at 4:59 AM, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > >> Hi! >> >> A question just popped up: Can Pharo handle very large files? I mean, can I open and navigate within a 1 Gb file? >> Someone has experience to share? > > As indicated its simply an issue if building the VM correctly. If you use a recent Cog VM from my site you'll be able to access beyond 4Gb (64-but file pointers). > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >>

Nov. 4, 2014

Browse anObject?

by Sean P. DeNigris

This one smells funny to me... Object>>#browse ^ self systemNavigation browseClass: self class A less surprising API might be: - Object>>#browseClass - and, Class>>#browse as implemented above What do you think? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Browse-anObject-tp4788401.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 4, 2014

Re: [Pharo-dev] A configuration framework

by Thierry Goubier

Hi Damien, I use a small extension to SystemSettings which handles checking that the target class exist before executing the setting. However you lose the runOnce ability. Thierry 2014-11-04 17:15 GMT+01:00 Damien Cassou <damien.cassou(a)gmail.com>: > Hi, > > I need a framework that will help me make my application configurable. > This framework must save and load the application's configuration > to/from a file. I'm not happy with the System-Settings framework (that > I'm currently using for the Pharo Launcher) that saves executable code > because, when the application evolves, the old code in the > configuration file might not work with the new application. > > Is there something around already? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Nov. 4, 2014