July 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Working with urls that contain non latin characters

by Herbert VojÄÃk

Offray Vladimir Luna CÃ¡rdenas wrote on 27. 7. 2018 12:39: > Hi, > > I was ready to show a friend the Pharo web capabilities with the > classical "myString asUrl retrieveContents", but the friend gave me a > url that contains non Latin characters[1] and then I got an > ZnInvalidUTF8 error. > > [1] > http://www.bidchance.com/freesearch.do?&filetype=&channel=&currentpage=1&se… > > How can I process web addresses in Pharo that contain non latin > characters like the one in [1]? Maybe you can make it into additional test case(s) in Zinc and upload them so authors (or anyone else willing to) can take on from that point and fix them. I also faintly remember Zinc having some problems when I worked with it and the need to devise workarounds around asUrl use. > Thanks, > > Offray

July 27, 2018

Working with urls that contain non latin characters

by Offray Vladimir Luna CÃ¡rdenas

Hi, I was ready to show a friend the Pharo web capabilities with the classical "myString asUrl retrieveContents", but the friend gave me a url that contains non Latin characters[1] and then I got an ZnInvalidUTF8 error. [1] http://www.bidchance.com/freesearch.do?&filetype=&channel=&currentpage=1&se… How can I process web addresses in Pharo that contain non latin characters like the one in [1]? Thanks, Offray

July 27, 2018

Re: [Pharo-users] SpecGenerator

by Stephan Eggermont

john pfersich <jpfersich(a)gmail.com> wrote: > I have a question about SpecGenerator. The video introducing SpecGenerator > about 2 years ago says you start it with: > MEApplicationList open. > > There's no open method in version 15 that I loaded from SmalltalkHub. > > How do you start the app? > > See the MEApplicationList class comment

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Norbert Hartl

> Am 26.07.2018 um 17:59 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Richard, > > I am only engaging in a discussion with you in order to explain what we did and why. The changes that we did were years in the making and are now being pushed into the system. The discussions happened long ago, we are not going to revert them. > > Of course you are entitled to have your own opinion and disagree. > > I do not know what 'your system' is that you are referring to. > > Pharo has a particular philosophy that includes a complex relationship with the concepts of Smalltalk and especially ANSI Smalltalk. In one sentence, we want to have to liberty to make (breaking) changes and don't want to be stuck in the past. At the same time we want our user base to be able to follow by adapting their code. > +1 Norbert > Regards, > > Sven > >> On 26 Jul 2018, at 17:06, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> Yes there was no mention of BOMs, but there *was* mention of >> #position, and the presence or absence of byte order marks >> makes a difference. >> >> As for mailing list discussions over a year, that is not the >> kind of single coherent source I was hoping for. >> >> As someone *using* the system classes, I don't give a damn >> how big they are. What I care about is the complexity of >> *my* code, and it looks as though the new interface will >> make my code bigger, more error-prone, and less portable. >> As for the "big hairy classes" sneer, the file stream >> classes put together in my system are about the same size >> as the Dictionary class proper. >> >> I don't "want to make users set environment variables". >> What I was suggesting was that if a user does go to the >> trouble of setting relevant environment variables, the >> system should have the decency to pay attention to them. >> >> handling /dev/std... is pretty trivial in UNIX; in Windows >> nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ >> amongst themselves in several annoying ways). >> >> I can make no sense of the comment that interpreting #'text' >> as #utf8 (always, as a design choice) or as whatever the >> user chose for $LC_CTYPE (always, as a design choice) is >> "not very Smalltalk like". Both design choices are fully >> consistent with the standard -- to the limited extent that >> UTF8 processing *can* be consistent with the standard. >> >> >> On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> >>> Oh, I think a clarification is needed when talking about UTF-8. >> >> Why ? >> >>> To the best of my knowledge you don't need a Byte-Order-Mark at >>> the beginning of a UTF-8 stream because there is no byte order >>> issue to result, >> >> Nothing was said about BOMs. >> >>> but apparently many Windows programs like to add one. >> >> Apparently yes. >> >>> Does/will Pharo add one when writing a UTF-8 file? >> >> No >> >>> Does/will it skip one when reading a UTF-8 file? >> >> Yes >> >>> I find the new approach produces unattractive code. I can do >>> all of the examples simply in a system that >>> (a) implements the ANSI Smalltalk FileStream class methods >> >> Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me. >> >> Do you prefer a global class side factory facade ? >> >> Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same). >> >>> (b) supports '/dev/stdin' and '/dev/stdout' as file names >> >> Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform. >> >>> (c) interprets the external type #'text' either as #'utf8' LC_CTYPE >> >> Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default. >> >>> What document should I read to get a mental model of the new >>> system and understand its rationale? >> >> ML discussions over the year, I guess. >> >> We are generally against big hairy complex classes and prefer simpler ones. >> >> >> > >

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

Richard, I am only engaging in a discussion with you in order to explain what we did and why. The changes that we did were years in the making and are now being pushed into the system. The discussions happened long ago, we are not going to revert them. Of course you are entitled to have your own opinion and disagree. I do not know what 'your system' is that you are referring to. Pharo has a particular philosophy that includes a complex relationship with the concepts of Smalltalk and especially ANSI Smalltalk. In one sentence, we want to have to liberty to make (breaking) changes and don't want to be stuck in the past. At the same time we want our user base to be able to follow by adapting their code. Regards, Sven > On 26 Jul 2018, at 17:06, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > Yes there was no mention of BOMs, but there *was* mention of > #position, and the presence or absence of byte order marks > makes a difference. > > As for mailing list discussions over a year, that is not the > kind of single coherent source I was hoping for. > > As someone *using* the system classes, I don't give a damn > how big they are. What I care about is the complexity of > *my* code, and it looks as though the new interface will > make my code bigger, more error-prone, and less portable. > As for the "big hairy classes" sneer, the file stream > classes put together in my system are about the same size > as the Dictionary class proper. > > I don't "want to make users set environment variables". > What I was suggesting was that if a user does go to the > trouble of setting relevant environment variables, the > system should have the decency to pay attention to them. > > handling /dev/std... is pretty trivial in UNIX; in Windows > nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ > amongst themselves in several annoying ways). > > I can make no sense of the comment that interpreting #'text' > as #utf8 (always, as a design choice) or as whatever the > user chose for $LC_CTYPE (always, as a design choice) is > "not very Smalltalk like". Both design choices are fully > consistent with the standard -- to the limited extent that > UTF8 processing *can* be consistent with the standard. > > > On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > Oh, I think a clarification is needed when talking about UTF-8. > > Why ? > > > To the best of my knowledge you don't need a Byte-Order-Mark at > > the beginning of a UTF-8 stream because there is no byte order > > issue to result, > > Nothing was said about BOMs. > > > but apparently many Windows programs like to add one. > > Apparently yes. > > > Does/will Pharo add one when writing a UTF-8 file? > > No > > > Does/will it skip one when reading a UTF-8 file? > > Yes > > > I find the new approach produces unattractive code. I can do > > all of the examples simply in a system that > > (a) implements the ANSI Smalltalk FileStream class methods > > Given a FileReference object of some kind you ask for the streams you need. Seems pretty OO if you ask me. > > Do you prefer a global class side factory facade ? > > Both approaches are not exclusive per se, we just want a clear break/difference (because the resulting streams are not 100% the same). > > > (b) supports '/dev/stdin' and '/dev/stdout' as file names > > Maybe, with special casing. I like 'Stdio stdout' better as it is more cross platform. > > > (c) interprets the external type #'text' either as #'utf8' LC_CTYPE > > Maybe, but that is not very Smalltalk like is it ? You want users to set environment variables ? Anyway this is less important point as UTF-8 is (should be) the general default. > > > What document should I read to get a mental model of the new > > system and understand its rationale? > > ML discussions over the year, I guess. > > We are generally against big hairy complex classes and prefer simpler ones. > > >

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Richard O'Keefe

Yes there was no mention of BOMs, but there *was* mention of #position, and the presence or absence of byte order marks makes a difference. As for mailing list discussions over a year, that is not the kind of single coherent source I was hoping for. As someone *using* the system classes, I don't give a damn how big they are. What I care about is the complexity of *my* code, and it looks as though the new interface will make my code bigger, more error-prone, and less portable. As for the "big hairy classes" sneer, the file stream classes put together in my system are about the same size as the Dictionary class proper. I don't "want to make users set environment variables". What I was suggesting was that if a user does go to the trouble of setting relevant environment variables, the system should have the decency to pay attention to them. handling /dev/std... is pretty trivial in UNIX; in Windows nothing about stdin is easy (XP, Vista, 7, 8, and 10 differ amongst themselves in several annoying ways). I can make no sense of the comment that interpreting #'text' as #utf8 (always, as a design choice) or as whatever the user chose for $LC_CTYPE (always, as a design choice) is "not very Smalltalk like". Both design choices are fully consistent with the standard -- to the limited extent that UTF8 processing *can* be consistent with the standard. On 24 July 2018 at 05:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 23 Jul 2018, at 18:52, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > Oh, I think a clarification is needed when talking about UTF-8. > > Why ? > > > To the best of my knowledge you don't need a Byte-Order-Mark at > > the beginning of a UTF-8 stream because there is no byte order > > issue to result, > > Nothing was said about BOMs. > > > but apparently many Windows programs like to add one. > > Apparently yes. > > > Does/will Pharo add one when writing a UTF-8 file? > > No > > > Does/will it skip one when reading a UTF-8 file? > > Yes > > > I find the new approach produces unattractive code. I can do > > all of the examples simply in a system that > > (a) implements the ANSI Smalltalk FileStream class methods > > Given a FileReference object of some kind you ask for the streams you > need. Seems pretty OO if you ask me. > > Do you prefer a global class side factory facade ? > > Both approaches are not exclusive per se, we just want a clear > break/difference (because the resulting streams are not 100% the same). > > > (b) supports '/dev/stdin' and '/dev/stdout' as file names > > Maybe, with special casing. I like 'Stdio stdout' better as it is more > cross platform. > > > (c) interprets the external type #'text' either as #'utf8' LC_CTYPE > > Maybe, but that is not very Smalltalk like is it ? You want users to set > environment variables ? Anyway this is less important point as UTF-8 is > (should be) the general default. > > > What document should I read to get a mental model of the new > > system and understand its rationale? > > ML discussions over the year, I guess. > > We are generally against big hairy complex classes and prefer simpler ones. > > >

July 26, 2018

Re: [Pharo-users] Pharo7, consistent image freeze/deadlock on snapshotAndQuit

by Ben Coman

I don't have a total answer, but can confirm the problem and help characterize it. First, great test-snippet. Really nice and concise. On Windows it indeed freezes my Pharo 7 image when saving the image. It doesn't freeze Pharo 6. It doesn't freeze if the test-processes are not terminated. It doesn't freeze if the shutdown code runs at a lower priority that the test-processes. i.e. it works with these added lines... shutDown: quitting "+" |restorePriority| "+" restorePriority := Processor activeProcess priority. "+" Processor activeProcess priority: 15. Process1 ifNotNil:[ Process1 terminate ]. Process2 ifNotNil: [Process2 terminate ]. "+" Processor activeProcess priority: restorePriority. Process1 := Process2 := nil Does that help someone else identify the relevant changes between Pharo 6 & 7 to explain the behaviour in more depth. cheers -ben On 26 July 2018 at 00:46, Johan Brichau <johan(a)inceptive.be> wrote: > Hi, > > I ran into a freeze issue when trying to save and/or quit an image after loading Seaside3 and Zinc (not an infrequent combination :) > > The cause seems to be that terminating processes in a `shutDown` handler (called on image shutdown / snapshot) leads to a deadlock (somewhere). > Both Comet and Zinc will send #terminate to a process when an image is quit or saved. If I disable one of those, the deadlock does not occur. > > I managed to reconstruct the issue with a simple example, attached. > > The attached Freeze class creates two processes (that loop with a Delay>>wait inside) in the `startUp` method (on image start). > These processes are terminated by the shutdown method (called on image quit/save). > However, when you try to quit and/or save the image, you will experience an image freeze. > > Iâm not familiar with the process scheduler, or anything else in this contextâ¦ so help would be appreciated while I try to dive further into it :) > > To reproduce: just file in the attached file in a Pharo7 image and try to quit. > For reference, System Reporter output for my configuration. > > Any ideas? > > Cheers > Johan > > > > > Image > ----- > /Users/jbrichau/Pharo/images/Pharo 7.0 - 64bit (development version)/Pharo 7.0 - 64bit (development version).image > Pharo7.0alpha > Build information: Pharo-7.0+alpha.build.1131.sha.a46bfaef44ba209888c92fa0e3bd3a5e04a38c5d (64 Bit) > Unnamed > > Virtual Machine > --------------- > /Users/jbrichau/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > Mac OS X built on Jun 28 2018 13:07:33 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) > VMMaker versionString VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > >

July 26, 2018

Re: [Pharo-users] Status of Caffeine

by Siemen Baader

Hi again, I played a bit with the online demo. Do you have implemented a basic file browser with DOM (not canvas) UI? But it is not compatible at the Morphic level, right? So it is not a DOM element based backend that existing Morphic applications could use..? Also, what happens when you have an exception in code in a DOM callback like xhr completed or a click event? Does it pop up a real Squeak debugger and allows coding in the debugger like real smalltalk? Cheers, Siemen Sent from my iPhone > On 20 Jul 2018, at 11.27, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Ok, Thanks! > > :) > Siemen > > Sent from my iPhone > >> On 20 Jul 2018, at 10.08, Craig Latta <craig(a)blackpagedigital.com> wrote: >> >> >>> What about the UI lag and the occasional spinner that blocks the UI, >>> is this related to the debugging protocol (I see that the IDEs are >>> loaded in iframes) that will go away when run from local, or is this >>> something that can be optimized away? >> >> That's just the speed of Morphic. The VM is set up to display the >> spinner whenever anything takes more than a certain amount of time (one >> alternative is to just turn it off :). While Morphic in SqueakJS has >> gotten a lot faster since the first release, just because JavaScript >> engines have gotten faster, I was still motivated to explore >> alternatives. That's why I experimented with animated HTML wireframes, >> morphic.js from Snap, and using a separate HMTL5 canvas for each morph. >> >> All three of these approaches are much faster than traditional >> Morphic. However, the traditional Morphic UI has the appeal that it's >> pixel-portable between the Web and native apps. >> >> >> thanks again, >> >> -C >> >> -- >> Craig Latta >> Black Page Digital >> Amsterdam :: San Francisco >> craig(a)blackpagedigital.com >> +31 6 2757 7177 (SMS ok) >> + 1 415 287 3547 (no SMS) >>

July 26, 2018

SpecGenerator

by john pfersich

I have a question about SpecGenerator. The video introducing SpecGenerator about 2 years ago says you start it with: MEApplicationList open. There's no open method in version 15 that I loaded from SmalltalkHub. How do you start the app?

July 26, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by David T. Lewis

On Wed, Jul 25, 2018 at 02:20:30PM +0200, Damien Pollet wrote: > On Wed, 25 Jul 2018 at 13:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 25 Jul 2018, at 13:39, Damien Pollet <damien.pollet+pharo(a)gmail.com> > > wrote: > > > Related issue: command line arguments come from VM system attributes as > > ByteStrings??? and thus interpreted as iso-8859-1, which is incorrect in most > > cases nowadays, even though it seems to work as long as you only use ASCII. > > Decoding them is easy enough, but it requires two copies (asByteString > > utf8Decoded) > > > > Yes this is a really big issue. Anything coming in as command line arg or > > environment variable (or clipboard) is in a basically unknown OS determined > > encoding. I would assume/hope the UTF-8 is the sensible default today, but > > apparently not. And it is hard to find a cross platform solution. > > > > My point here was that it would make more sense for those to be passed into > the image as ByteArrays, revealing the fact that their encoding is unknown. > Currently the bytes are correct, but since they've been shoved into > ByteStrings by the VM, the characters will be wrong unless your system > happens to be using Latin 1. That sounds right to me. Having said that, there should be no need to change the VM interface to do this. A ByteString is by definition an array of 8 bit wide characters, and conversion between ByteString and ByteArray is trivial. Any necessary changes can be done without touching the VM. Dave > > I suppose we can either have a setting for decoding (since it's pretty much > arbitrary), or heuristics like checking LC_CTYPE or whatever. Pablo > mentioned the Locale class, but it doesn't seem to detect anything correct > from the environment.

July 26, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Peter UhnÃ¡k

> Actually I do not think that the above is that bad ;-) It is too explicit for me and easy to forget to do. :) > I guess you could add some extension methods to NeoJSONWriter, or subclass it - yourself. In the end, this is probably the most reasonable. And I can change some of the defaults too (like pretty printing & LF line ending). Thanks for the discussion! Peter On Wed, Jul 25, 2018 at 7:21 PM, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Just as a comment to Henrik, NeoJSON will already preserve the order of an > OrderedDictionary. When working with Stef on the HTML scraping booklet, I > decided to find a way to preserve the order of the selected items, partly > for aesthetic reasons, but mainly to demonstrate that the output matched > the > problem specification. I switched the collection of the output items to an > OrderedDictionary, not knowing whether it would work, and it came out as > expected. Building an OrderedDictionary of just the required instvars would > solve both the OP's problems, though perhaps less elegantly. > > Peter Kenny > > -----Original Message----- > From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Sven > Van Caekenberghe > Sent: 25 July 2018 17:49 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] NeoJSON sorting instance variables/properties > > > > > On 25 Jul 2018, at 17:54, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > > > Hi Peter, > > > > This functionallity is already available in STON where it preserves > > the order when you use an OrderedDictionary. > > And was implemented for the usecase of dealing with fileout and > versioning. > > Perhaps the same could be added to NeoJson so that instead of some > > magic flag you provide an OrderedDictionary sorted as you would like > > and it would then preserve the order. > > You are right, using OrderedDictionaries would fix the order. > > But I don't think that is what he wants: to fix the order of arbitrary > objects being mapped. > > Even in STON the order of properties of objects is undefined (as it is in > JSON). > > > If you aim to use it to preserve metada for filetree then there is a > > patch for that which can be found at > > https://github.com/DraagrenKirneh/PharoUtilities/tree/master/FileTreeF > > ix > > > > Best regards, > > Henrik > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > >

July 25, 2018

Re: [Pharo-users] OmniBase for Pharo 6

by PBKResearch

Marco Thanks for this. Just for curiosity, did you test it just on Windows, or on other OSs as well. The logic of the Dec 2010 fix was that David GorisekÂs original, being developed on Dolphin, could not be guaranteed to work except on Windows. I only use Windows, so it is just curiosity. BTW, the author of the Dec 2010 fix, ÂsasÂ, is Sebastian Sastre, so definitely ÂheÂ. Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Matias Maretto Sent: 25 July 2018 13:34 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] OmniBase for Pharo 6 Marco: thank you for this. A few weeks ago when I was trying to find the "lock" problem I saw this method but I did not dare to change it; and just as you said I been using OminBase with no problem, but never runned the Garbage Collector, Surely I was going to have a bigger problem in the future for not running the garbageCollect. I have just update this method on my project and tried both the garbageCollect and the reorganize method , both worked fine (win 7 32bits, later I am going to test on Win 10 64 bits). Thanks again. MatÃas. _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de marco <marco(a)omeleon.de <mailto:marco@omeleon.de> > Enviado: miÃ©rcoles, 25 de julio de 2018 10:23 a. m. Para: pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> Asunto: Re: [Pharo-users] OmniBase for Pharo 6 One serious problem left: OmniBaseTest>>testGC fails. Have a look at the 2 methods /ODBContainer>>lockDataFile "Dec, 2010 sas: this code was relying in evaluating a block that was happening only in win32 but not in *nix. So now I'm making it wait for the lock and then execute the code normally because it seems the intention was the same." | currentSpace defaultSpace | activeDataFile waitForAddingLock. currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile] ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock "Wait for lock at given position. Evaluate aBlock in each iteration." "Dec, 2010. sas: evaluating code in each iteration while waiting sounds weird but whatever. I think this was designed on the wrong assumption that the OS always will provide a false in the first try but what actually happens is that in win32 you always will get at least one false but in *nixes you don't do see that happening (which is totally reasonable). BEWARE of stupid code relying on this stupid assumption (I've already patched #lockDataFile because of this)." | startTime currentTime | (stream lockAt: pos length: length) ifFalse: [ startTime := Time totalSeconds. [stream lockAt: pos length: length] whileFalse: [ aBlock value. currentTime := Time totalSeconds. currentTime - startTime < self timeOutLength ifFalse: [ ODBLockNotification signal ifTrue: [startTime := currentTime] ifFalse: [^ODBCannotLock signal]]]] / So "sas" did a refactoring in 2010 because he/she thought it is stupid code. This code change breaks the GarbageCollection of Omnibase. I reverted the first method to the original code of the Omnibase author, David Gorisek: /lockDataFile | currentSpace defaultSpace | activeDataFile waitForAddingLockWhileWaitingDo: [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile]] / I removed the comment of "sas" from the second method. It is wrong. The garbage collection works again and the test is green. GC is an important feature of Omnibase. It creates a new repository/database file and copies the data into the new file, compressing the data. It keeps your database compact and clean. If you don't run it (frequently) your db files keep on growing... Matias, your fixes are absolutely valid and should be published - together with the one above - in Esteban's repository. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> Smalltalk - Pharo Smalltalk Users | Mailing List Archive forum.world.st Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum

July 25, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by PBKResearch

Just as a comment to Henrik, NeoJSON will already preserve the order of an OrderedDictionary. When working with Stef on the HTML scraping booklet, I decided to find a way to preserve the order of the selected items, partly for aesthetic reasons, but mainly to demonstrate that the output matched the problem specification. I switched the collection of the output items to an OrderedDictionary, not knowing whether it would work, and it came out as expected. Building an OrderedDictionary of just the required instvars would solve both the OP's problems, though perhaps less elegantly. Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Sven Van Caekenberghe Sent: 25 July 2018 17:49 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] NeoJSON sorting instance variables/properties > On 25 Jul 2018, at 17:54, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > Hi Peter, > > This functionallity is already available in STON where it preserves > the order when you use an OrderedDictionary. > And was implemented for the usecase of dealing with fileout and versioning. > Perhaps the same could be added to NeoJson so that instead of some > magic flag you provide an OrderedDictionary sorted as you would like > and it would then preserve the order. You are right, using OrderedDictionaries would fix the order. But I don't think that is what he wants: to fix the order of arbitrary objects being mapped. Even in STON the order of properties of objects is undefined (as it is in JSON). > If you aim to use it to preserve metada for filetree then there is a > patch for that which can be found at > https://github.com/DraagrenKirneh/PharoUtilities/tree/master/FileTreeF > ix > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 25, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Sven Van Caekenberghe

> On 25 Jul 2018, at 17:54, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > Hi Peter, > > This functionallity is already available in STON where it preserves the > order when you use an OrderedDictionary. > And was implemented for the usecase of dealing with fileout and versioning. > Perhaps the same could be added to NeoJson so that instead of some magic > flag you provide an OrderedDictionary sorted as you would like and it would > then preserve the order. You are right, using OrderedDictionaries would fix the order. But I don't think that is what he wants: to fix the order of arbitrary objects being mapped. Even in STON the order of properties of objects is undefined (as it is in JSON). > If you aim to use it to preserve metada for filetree then there is a patch > for that which can be found at > https://github.com/DraagrenKirneh/PharoUtilities/tree/master/FileTreeFix > > Best regards, > Henrik > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

July 25, 2018

Pharo7, consistent image freeze/deadlock on snapshotAndQuit

by Johan Brichau

Hi, I ran into a freeze issue when trying to save and/or quit an image after loading Seaside3 and Zinc (not an infrequent combination :) The cause seems to be that terminating processes in a `shutDown` handler (called on image shutdown / snapshot) leads to a deadlock (somewhere). Both Comet and Zinc will send #terminate to a process when an image is quit or saved. If I disable one of those, the deadlock does not occur. I managed to reconstruct the issue with a simple example, attached. The attached Freeze class creates two processes (that loop with a Delay>>wait inside) in the `startUp` method (on image start). These processes are terminated by the shutdown method (called on image quit/save). However, when you try to quit and/or save the image, you will experience an image freeze. Iâm not familiar with the process scheduler, or anything else in this contextâ¦ so help would be appreciated while I try to dive further into it :) To reproduce: just file in the attached file in a Pharo7 image and try to quit. For reference, System Reporter output for my configuration. Any ideas? Cheers Johan Image ----- /Users/jbrichau/Pharo/images/Pharo 7.0 - 64bit (development version)/Pharo 7.0 - 64bit (development version).image Pharo7.0alpha Build information: Pharo-7.0+alpha.build.1131.sha.a46bfaef44ba209888c92fa0e3bd3a5e04a38c5d (64 Bit) Unnamed Virtual Machine --------------- /Users/jbrichau/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Mac OS X built on Jun 28 2018 13:07:33 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) VMMaker versionString VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018

July 25, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Henrik-Nergaard

Hi Peter, This functionallity is already available in STON where it preserves the order when you use an OrderedDictionary. And was implemented for the usecase of dealing with fileout and versioning. Perhaps the same could be added to NeoJson so that instead of some magic flag you provide an OrderedDictionary sorted as you would like and it would then preserve the order. If you aim to use it to preserve metada for filetree then there is a patch for that which can be found at https://github.com/DraagrenKirneh/PharoUtilities/tree/master/FileTreeFix Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 25, 2018

Re: [Pharo-users] NeoJSON sorting instance variables/properties

by Sven Van Caekenberghe

> On 25 Jul 2018, at 11:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Ah, you are right that it might not be human-friendly. > > I don't want to rely on the order, but for (file) versioning it is quite valuable. (or rather changing the order can easily make versioning quite worthless). Ah, OK, I understand the use case. > I can manually sort it, but it creates a lot of mess: > > (NeoJSONWriter on: stream) > prettyPrint: true; > for: Something > do: [ :mapping | mapping mapInstVars: (mapping identifier instVarNames \ #(unwanted)) sorted ]; > for: Otherthing > do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames sorted ]; > for: Point > do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames sorted ]; > nextPut: anObject. Actually I do not think that the above is that bad ;-) > I'd much rather have the following: > > (NeoJSONWriter on: stream) > prettyPrint: true; > sorted: true; > for: Something > do: [ :mapping | mapping mapInstVars: mapping identifier instVarNames \ #(unwanted) ]; > mapInstVarsFor: Otherthing; > mapInstVarsFor: Point; > nextPut: anObject. > > or more fine-grained, although the above is imo nicer: > > (NeoJSONWriter on: stream) > prettyPrint: true; > for: Something > do: [ :mapping | mapping mapInstVars: (mapping identifier instVarNames \ #(unwanted)) sorted ]; > mapInstVarsFor: Otherthing sorted: true; > mapInstVarsFor: Point sorted: true; > nextPut: anObject. > > (or mapSortedInstVarsFor: or something).. I guess you could add some extension methods to NeoJSONWriter, or subclass it - yourself. After some consideration I still think that adding sorting options would be confusing. Unless there would be some convention in other JSON tools for this issue, or a larger demand (more use cases). > Peter > > On Wed, Jul 25, 2018 at 11:20 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > From json.org > > "An object is an unordered set of name/value pairs." > > IOW, it is not in the spec, it would be dangerous to rely up it in any way (not that you are suggesting that). It might look better sometimes, but even then alphabetic sorting might not be the most human friendly or most meaningful. > > Note that 'properties' in NeoJSONMapping is an OrderedCollection, so it keeps it order. So if you add them in the right order, that would do it. > > > On 25 Jul 2018, at 11:12, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > would it be possible to provide option to automatically sort instance variables when serializing objects? > > > > Either always sorted > > > > NeoJSONObjectMapping>>writeObject: anObject on: jsonWriter > > jsonWriter writeMapStreamingDo: [ :jsonMapWriter | > > (properties sorted: #propertyName ascending) do: [ :each | > > each writeObject: anObject on: jsonMapWriter ] ] > > > > or put it behind some sortProperties boolean flag. (atm I don't see any downsides in having sort always enabled) > > Speed ? > A false suggestion that is part of the spec ? > > > Thanks, > > Peter

July 25, 2018

Re: [Pharo-users] Using Icerberg programmatically.

by Arturo Zambrano

Hi Guille. thanks for the advise. I will use it carefully, and try to move to Pharo 7 soon. Arturo On Wed, Jul 25, 2018 at 5:02 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Arturo, > > First, I would not recommend too much to use the version on Pharo 6.1. > That version is a preview version that is >6 months older than the new one > in Pharo 7. This does not mean you cannot write a script, but we do not > guarantee it will work in more recent version :). > > If you then settle for the version on Pharo7, something you have to also > care about is that while most of the basic API is stable enough, some > others will evolve in the near future. There are many missing features, and > we are trying to keep it as simple as possible so it can easily evolve... > > Just a note about what you want to do: Be careful with programmatic > pulling. A pull is a fetch + a merge. If you did not commit in your branch, > the merge will be a simple fast-forward and you will have no further > problems. But if you did commit, you will have a merge, with potentially > conflicts. And conflicts have so far to be manually resolved. > > Guille > > On Wed, Jul 25, 2018 at 9:51 AM Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > >> Hi Arthur, >> >> The starting point is the IceRepository. >> You can build you own repository with IceRepositoryCreator or get an >> existing one from IceRepository registry. >> Then on the repository you can call #pull. >> >> Christophe >> >> > Le 24 juil. 2018 Ã 20:09, Arturo Zambrano <arturo.zambrano(a)gmail.com> >> a Ã©crit : >> > >> > Hi All, >> > the new Iceberg is really cool. I'm using it in Pharo 6.1. >> > >> > Is there some documentation or script examples on how to use >> Iceberg programmatically? I would like to write an script to pull changes >> to an existing repository, before doing some other stuff. I can do it with >> the UI, but I would like to automatize it. Any pointer is welcome. >> > >> > Thanks in advance. >> > Arturo >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

July 25, 2018

Re: [Pharo-users] Using Icerberg programmatically.

by Arturo Zambrano

Thanks Christophe, that's what I was looking for. Arturo On Wed, Jul 25, 2018 at 4:51 AM Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hi Arthur, > > The starting point is the IceRepository. > You can build you own repository with IceRepositoryCreator or get an > existing one from IceRepository registry. > Then on the repository you can call #pull. > > Christophe > > > Le 24 juil. 2018 Ã 20:09, Arturo Zambrano <arturo.zambrano(a)gmail.com> a > Ã©crit : > > > > Hi All, > > the new Iceberg is really cool. I'm using it in Pharo 6.1. > > > > Is there some documentation or script examples on how to use Iceberg > programmatically? I would like to write an script to pull changes to an > existing repository, before doing some other stuff. I can do it with the > UI, but I would like to automatize it. Any pointer is welcome. > > > > Thanks in advance. > > Arturo > > >

July 25, 2018

Re: [Pharo-users] OmniBase for Pharo 6

by Matias Maretto

Marco: thank you for this. A few weeks ago when I was trying to find the "lock" problem I saw this method but I did not dare to change it; and just as you said I been using OminBase with no problem, but never runned the Garbage Collector, Surely I was going to have a bigger problem in the future for not running the garbageCollect. I have just update this method on my project and tried both the garbageCollect and the reorganize method , both worked fine (win 7 32bits, later I am going to test on Win 10 64 bits). Thanks again. MatÃas. ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org> en nombre de marco <marco(a)omeleon.de> Enviado: miÃ©rcoles, 25 de julio de 2018 10:23 a. m. Para: pharo-users(a)lists.pharo.org Asunto: Re: [Pharo-users] OmniBase for Pharo 6 One serious problem left: OmniBaseTest>>testGC fails. Have a look at the 2 methods /ODBContainer>>lockDataFile "Dec, 2010 sas: this code was relying in evaluating a block that was happening only in win32 but not in *nix. So now I'm making it wait for the lock and then execute the code normally because it seems the intention was the same." | currentSpace defaultSpace | activeDataFile waitForAddingLock. currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile] ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock "Wait for lock at given position. Evaluate aBlock in each iteration." "Dec, 2010. sas: evaluating code in each iteration while waiting sounds weird but whatever. I think this was designed on the wrong assumption that the OS always will provide a false in the first try but what actually happens is that in win32 you always will get at least one false but in *nixes you don't do see that happening (which is totally reasonable). BEWARE of stupid code relying on this stupid assumption (I've already patched #lockDataFile because of this)." | startTime currentTime | (stream lockAt: pos length: length) ifFalse: [ startTime := Time totalSeconds. [stream lockAt: pos length: length] whileFalse: [ aBlock value. currentTime := Time totalSeconds. currentTime - startTime < self timeOutLength ifFalse: [ ODBLockNotification signal ifTrue: [startTime := currentTime] ifFalse: [^ODBCannotLock signal]]]] / So "sas" did a refactoring in 2010 because he/she thought it is stupid code. This code change breaks the GarbageCollection of Omnibase. I reverted the first method to the original code of the Omnibase author, David Gorisek: /lockDataFile | currentSpace defaultSpace | activeDataFile waitForAddingLockWhileWaitingDo: [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile]] / I removed the comment of "sas" from the second method. It is wrong. The garbage collection works again and the test is green. GC is an important feature of Omnibase. It creates a new repository/database file and copies the data into the new file, compressing the data. It keeps your database compact and clean. If you don't run it (frequently) your db files keep on growing... Matias, your fixes are absolutely valid and should be published - together with the one above - in Esteban's repository. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html Smalltalk - Pharo Smalltalk Users | Mailing List Archive<http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> forum.world.st Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum

July 25, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Damien Pollet

On Wed, 25 Jul 2018 at 13:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 25 Jul 2018, at 13:39, Damien Pollet <damien.pollet+pharo(a)gmail.com> > wrote: > > Related issue: command line arguments come from VM system attributes as > ByteStringsâ¦ and thus interpreted as iso-8859-1, which is incorrect in most > cases nowadays, even though it seems to work as long as you only use ASCII. > Decoding them is easy enough, but it requires two copies (asByteString > utf8Decoded) > > Yes this is a really big issue. Anything coming in as command line arg or > environment variable (or clipboard) is in a basically unknown OS determined > encoding. I would assume/hope the UTF-8 is the sensible default today, but > apparently not. And it is hard to find a cross platform solution. > My point here was that it would make more sense for those to be passed into the image as ByteArrays, revealing the fact that their encoding is unknown. Currently the bytes are correct, but since they've been shoved into ByteStrings by the VM, the characters will be wrong unless your system happens to be using Latin 1. I suppose we can either have a setting for decoding (since it's pretty much arbitrary), or heuristics like checking LC_CTYPE or whatever. Pablo mentioned the Locale class, but it doesn't seem to detect anything correct from the environment.

July 25, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Sven Van Caekenberghe

> On 25 Jul 2018, at 13:39, Damien Pollet <damien.pollet+pharo(a)gmail.com> wrote: > > On Tue, 24 Jul 2018 at 11:39, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So, > > Stdio stdout > > should return return a character write stream with UTF-8 encoding while > > Stdio binaryStdout > > should be the lower level binary one. > This would be more in line with the other streams. > A non-UTF-8 encoding can be used as per Pavel's example. > > +1 > > I didn't suggest this earlier because it isn't backward compatible. But I do think it is the better solution. > > +2 > > I had a look at Stdio recently for Clap. The current implementation with Stdio stdout returning the binary stream is a bit confusing, but at least you can wrap it. > The above proposition with an explicit binaryStdout for the lower level uncommon case would be much clearer indeed. > > Related issue: command line arguments come from VM system attributes as ByteStringsâ¦ and thus interpreted as iso-8859-1, which is incorrect in most cases nowadays, even though it seems to work as long as you only use ASCII. Decoding them is easy enough, but it requires two copies (asByteString utf8Decoded) Yes this is a really big issue. Anything coming in as command line arg or environment variable (or clipboard) is in a basically unknown OS determined encoding. I would assume/hope the UTF-8 is the sensible default today, but apparently not. And it is hard to find a cross platform solution. We've had serious issues already with this, like $HOME set to a non-ASCII path that then breaks almost everything.

July 25, 2018

Re: [Pharo-users] Pharo 7 file streams guideline

by Damien Pollet

On Tue, 24 Jul 2018 at 11:39, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > On 23 Jul 2018, at 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> So, >> >> Stdio stdout >> >> should return return a character write stream with UTF-8 encoding while >> >> Stdio binaryStdout >> >> should be the lower level binary one. >> This would be more in line with the other streams. >> A non-UTF-8 encoding can be used as per Pavel's example. >> > > +1 > > I didn't suggest this earlier because it isn't backward compatible. But I > do think it is the better solution. > +2 I had a look at Stdio recently for Clap. The current implementation with Stdio stdout returning the binary stream is a bit confusing, but at least you can wrap it. The above proposition with an explicit binaryStdout for the lower level uncommon case would be much clearer indeed. Related issue: command line arguments come from VM system attributes as ByteStringsâ¦ and thus interpreted as iso-8859-1, which is incorrect in most cases nowadays, even though it seems to work as long as you only use ASCII. Decoding them is easy enough, but it requires two copies (asByteString utf8Decoded)

July 25, 2018

Re: [Pharo-users] OmniBase for Pharo 6

by marco

One serious problem left: OmniBaseTest>>testGC fails. Have a look at the 2 methods /ODBContainer>>lockDataFile "Dec, 2010 sas: this code was relying in evaluating a block that was happening only in win32 but not in *nix. So now I'm making it wait for the lock and then execute the code normally because it seems the intention was the same." | currentSpace defaultSpace | activeDataFile waitForAddingLock. currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile] ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock "Wait for lock at given position. Evaluate aBlock in each iteration." "Dec, 2010. sas: evaluating code in each iteration while waiting sounds weird but whatever. I think this was designed on the wrong assumption that the OS always will provide a false in the first try but what actually happens is that in win32 you always will get at least one false but in *nixes you don't do see that happening (which is totally reasonable). BEWARE of stupid code relying on this stupid assumption (I've already patched #lockDataFile because of this)." | startTime currentTime | (stream lockAt: pos length: length) ifFalse: [ startTime := Time totalSeconds. [stream lockAt: pos length: length] whileFalse: [ aBlock value. currentTime := Time totalSeconds. currentTime - startTime < self timeOutLength ifFalse: [ ODBLockNotification signal ifTrue: [startTime := currentTime] ifFalse: [^ODBCannotLock signal]]]] / So "sas" did a refactoring in 2010 because he/she thought it is stupid code. This code change breaks the GarbageCollection of Omnibase. I reverted the first method to the original code of the Omnibase author, David Gorisek: /lockDataFile | currentSpace defaultSpace | activeDataFile waitForAddingLockWhileWaitingDo: [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1]. defaultSpace := objectManager defaultObjectSpace. currentSpace == defaultSpace ifFalse: [defaultSpace == 0 ifTrue: [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage openOn: self dataFileNameA]. activeDataFile := dataFileA] ifFalse: [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage openOn: self dataFileNameB]. activeDataFile := dataFileB]. ^self lockDataFile]] / I removed the comment of "sas" from the second method. It is wrong. The garbage collection works again and the test is green. GC is an important feature of Omnibase. It creates a new repository/database file and copies the data into the new file, compressing the data. It keeps your database compact and clean. If you don't run it (frequently) your db files keep on growing... Matias, your fixes are absolutely valid and should be published - together with the one above - in Esteban's repository. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

July 25, 2018

Dynabook learning model

by Hilaire

A critic view on the underneath learning model of the Dynabook: http://blog.drgeo.eu/post/2018/The-Dynabook-and-its-learning-models Hilaire -- Dr. Geo http://drgeo.eu

July 25, 2018