December 2017 - Pharo-users

Re: [Pharo-users] FLSerialization>>analysisStep too slow?

by Stephane Ducasse

Do you want that I help you defining a configuration for your project? Stef On Sat, Dec 16, 2017 at 9:10 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi eno > > can you tell us what is TkIDE? > Because most of us are hobbysts .... the truth is in the eye of the beholder :) > > Stef > > On Tue, Dec 12, 2017 at 3:47 PM, Eno <tgkuo1(a)gmail.com> wrote: >> >> My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on >> object database, sandstone, to store the objects. >> >> After upgrade to 6.1 on macOS, the save process became very slow. >> >> Following the debugging process, I found the bottle neck is at this method, >> FLSerialization>>analysisStep. >> >> I'm just a hobbyst, not acquainted with the system core and basis packages, >> I cann't figure out what the cause, just guessing maybe my object is too >> complicated to be serialized or the FLserialization really gets something >> wrong. >> >> Best reguards. >> >> Eno >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>

Dec. 16, 2017

Re: [Pharo-users] FLSerialization>>analysisStep too slow?

by Stephane Ducasse

Hi eno can you tell us what is TkIDE? Because most of us are hobbysts .... the truth is in the eye of the beholder :) Stef On Tue, Dec 12, 2017 at 3:47 PM, Eno <tgkuo1(a)gmail.com> wrote: > > My package TkIDE <http://smalltalkhub.com/#!/~tgkuo/TkIDE> relied on > object database, sandstone, to store the objects. > > After upgrade to 6.1 on macOS, the save process became very slow. > > Following the debugging process, I found the bottle neck is at this method, > FLSerialization>>analysisStep. > > I'm just a hobbyst, not acquainted with the system core and basis packages, > I cann't figure out what the cause, just guessing maybe my object is too > complicated to be serialized or the FLserialization really gets something > wrong. > > Best reguards. > > Eno > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Dec. 16, 2017

Re: [Pharo-users] Working directory

by Stephane Ducasse

Hi ben We should think about it. Indeed. Now about the names. I'm wondering if they cover well enough the situation. In fact I would like to have imageDirectory (it exists but not in FileSystem) and workingDirectory (I would prefer startupDirectory or something like that). For me workingDirectory is totally unclear. Now this change is super important for making Pharo a good platform for script execution. So let me make it even nicer. Stef On Fri, Dec 15, 2017 at 10:14 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: >> >> Le 15/12/2017 Ã 21:24, Hilaire a Ã©crit : >> > In P3: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared >> > >> > In P7: >> > >> > FileSystem disk workingDirectory >> > =>File @ /home/hilaire >> > >> > Is it a bug? >> > >> >> Hi! >> >> In Pharo 3 >> >> workingDirectory = imageDirectory. >> >> In Pharo 7 >> >> workingDirectory = directory from where Pharo was launched. > > > just double-checking... > with equivalent shell commands... > $ DIR1 = `pwd` > $ $DIR2/pharo $DIR3/Pharo.image > > Pharo 3 ==> workingDirectory = $DIR3 > Pharo 7 ==> workingDirectory = $DIR1 > ? > > I wonder for such a semantic API change it might be good to > introduce #workDirectory and deprecate #workingDirectory > so the need for user-devs to change their code is more explicit. > It might make easier to have an auto-conversion rule #workingDirectory ==> > #imageDirectory, > and make it harder to shoot yourself in the foot producing cross-platform > libraries. > > cheers -ben > > >> >> >> Maybe you launched Pharo from the terminal with this command like this >> one? >> >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui >> Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image >> >> If you wish to use the old behaviour, you can replace `FileSystem disk >> workingDirectory` by `FileLocator imageDirectory asFileReference`. >> >> This change was done because, not getting the real working directory >> make it really hard to script things in Pharo. >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >

Dec. 16, 2017

Re: [Pharo-users] Working directory

by Ben Coman

On 16 December 2017 at 04:34, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 15/12/2017 Ã 21:24, Hilaire a Ã©crit : > > In P3: > > > > FileSystem disk workingDirectory > > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared > > > > In P7: > > > > FileSystem disk workingDirectory > > =>File @ /home/hilaire > > > > Is it a bug? > > > > Hi! > > In Pharo 3 > > workingDirectory = imageDirectory. > > In Pharo 7 > > workingDirectory = directory from where Pharo was launched. > just double-checking... with equivalent shell commands... $ DIR1 = `pwd` $ $DIR2/pharo $DIR3/Pharo.image Pharo 3 ==> workingDirectory = $DIR3 Pharo 7 ==> workingDirectory = $DIR1 ? I wonder for such a semantic API change it might be good to introduce #workDirectory and deprecate #workingDirectory so the need for user-devs to change their code is more explicit. It might make easier to have an auto-conversion rule #workingDirectory ==> #imageDirectory, and make it harder to shoot yourself in the foot producing cross-platform libraries. cheers -ben > > Maybe you launched Pharo from the terminal with this command like this one? > > Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui > Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image > > If you wish to use the old behaviour, you can replace `FileSystem disk > workingDirectory` by `FileLocator imageDirectory asFileReference`. > > This change was done because, not getting the real working directory > make it really hard to script things in Pharo. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Dec. 15, 2017

Re: [Pharo-users] Working directory

by Hilaire

Thanks for the update Le 15/12/2017 Ã 21:34, Cyril Ferlicot D. a Ã©critÂ : > If you wish to use the old behaviour, you can replace `FileSystem disk > workingDirectory` by `FileLocator imageDirectory asFileReference`. > > This change was done because, not getting the real working directory > make it really hard to script things in Pharo. -- Dr. Geo http://drgeo.eu

Dec. 15, 2017

Re: [Pharo-users] Working directory

by Hilaire

Oh, in a build for a DrGeo app based on P7, the working directory is one level highter to the image folder. So in P7, there are two different results for the working directory: the user home directory, and one level hight to image dir. What's the context? Where to look at? -- Dr. Geo http://drgeo.eu

Dec. 15, 2017

Re: [Pharo-users] Iceberg is cool!

by Stephane Ducasse

I need less features and more user friendly UI :) On Wed, Dec 13, 2017 at 12:42 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I just got back from vacation and prepared a new image to work on the current project. Well, I upgraded iceberg to 0.6.5 and everything works like expected. I can see nicely what my colleagues have done while I was away. I can update everything easily. And most important I can do changes and then cherry pick and commit. > > So even if people are complaining about missing features (they always do!) I can say that for a basic workflow (for me about 95% of my work) everything seems to be in place. So everyone should feel invited to add the missing pieces. > > Well done and thank you, > > Norbert >

Dec. 15, 2017

Re: [Pharo-users] Working directory

by Cyril Ferlicot D.

Le 15/12/2017 Ã 21:24, Hilaire a Ã©critÂ : > In P3: > > FileSystem disk workingDirectory > =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared > > In P7: > > FileSystem disk workingDirectory > =>File @ /home/hilaire > > Is it a bug? > Hi! In Pharo 3 workingDirectory = imageDirectory. In Pharo 7 workingDirectory = directory from where Pharo was launched. Maybe you launched Pharo from the terminal with this command like this one? Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared/pharo-ui Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared Pharo.image If you wish to use the old behaviour, you can replace `FileSystem disk workingDirectory` by `FileLocator imageDirectory asFileReference`. This change was done because, not getting the real working directory make it really hard to script things in Pharo. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 15, 2017

Working directory

by Hilaire

In P3: FileSystem disk workingDirectory =>File @ /home/hilaire/Travaux/Developpement/DrGeoII/Dev-pharo3.0/shared In P7: FileSystem disk workingDirectory =>File @ /home/hilaire Is it a bug? -- Dr. Geo http://drgeo.eu

Dec. 15, 2017

Re: [Pharo-users] Zinc JSON parsing error handling

by Esteban A. Maringolo

Is this Bittrex client available somewhere to play with? Regards! Esteban A. Maringolo 2017-12-13 3:59 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > With... > Object subclass: #BittrexResponse > instanceVariableNames: 'success message result' > classVariableNames: '' > package: 'Bittrex' > > Object subclass: #BittrexMarketSummary > instanceVariableNames: 'MarketName High Low Volume Last > BaseVolume TimeStamp Bid Ask OpenBuyOrders > OpenSellOrders PrevDay Created DisplayMarketName' > classVariableNames: '' > package: 'Bittrex' > > this code works great when the response holds good data... > ZnClient new > url: 'https://bittrex.com/api/v1.1/public/getmarketSummary?market=BTC-LTC > '; > enforceHttpSuccess: true; > accept: ZnMimeType applicationJson; > contentReader: [ :entity | |reader| > reader := (NeoJSONReader on: entity readStream). > reader for: BittrexResponse do: [:m| > m mapInstVar: #success. > m mapInstVar: #message. > (m mapInstVar: #result) valueSchema: #ResultArray]. > reader for: #ResultArray customDo: [ :mapping | > mapping listOfElementSchema: BittrexMarketSummary ]. > reader mapInstVarsFor: BittrexMarketSummary. > reader nextAs: BittrexResponse ]; > get. > > i.e. a raw response looking like this.... > (ZnClient new > url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=BTC-LTC > <https://bittrex.com/api/v1.1/public/getticker?market=BTC-LTC>'; > get) inspect. > ==> "'{""success"":true,""message"":"",""result"":[{"" > MarketName"":""BTC-LTC"",""High"":0.01982450,""Low"":0. > 01285257,""Volume"":1436429.81313360,""Last"":0.01842000," > "BaseVolume"":24841.17217724,""TimeStamp"":""2017-12-13T05: > 56:25.937"",""Bid"":0.01840001,""Ask"":0.01842000,"" > OpenBuyOrders"":10140,""OpenSellOrders"":6306,""PrevDay"":0.01439800,"" > Created"":""2014-02-13T00:00:00""}]}'" > > > But for bad response looking like this... > (ZnClient new > url: 'https://bittrex.com/api/v1.1/public/getmarketsummary?market=INVALID > '; > get) inspect. > ==> {"success":false,"message":"INVALID_MARKET","result":null} > > the JSON handling code fails deep in the call stack with an error > "NeoJSONParseError: [ expected" > which is not so friendly for users of the Bittrex library. > > What are the different/recommended approaches with Zinc > for catching JSON errors such that I can pass "message" > as a higher level Error up the stack to the Bittrex user. > > cheers -ben >

Dec. 14, 2017