September 2016 - Pharo-users

Re: [Pharo-users] PunQlite problems

by PBKResearch

Hi - just tried a further experiment, with more mysterious results. I created a database in memory with a subset of my data. This time the program will retrieve the values as well as the keys. However, the value presented is just the first 1024 bytes, i.e. the first buffer full. In addition, in the majority of cases the correct bytes are each followed by three zero bytes, e.g. the data begins: 3C 00 00 00 68 00 00 00 74 00 00 00 6D 00 00 00 6C 00 00 00 20 00 00 00 63 00 00 00 6C 00 00 00 Rather than the expected: 3C 68 74 6D 6C 20 63 6C. This affects 75 of the 88 cases in my trial database. I presume the insertion of the zero bytes took place in the writing stage, but I have no idea what is going on. Are there any known problems with PunQLite on pharo 5? Hello I am using Moose 6.0 (Pharo 5.0 Latest update: #50761) on Windows 10. I have installed PunQLite following the instructions in https://github.com/mumez/PunQLite. I have run all the examples that involve using files, and everything seems OK. I have tried creating a database using my own data, which seemed to run OK. The database will display its keys successfully, but whenever I try to retrieve a value I get PqFetchError. The debug information shows that an ffi fetch operation has given a return value of -10. I have searched for any information on unQLite return codes, but so far I have nothing. I tried the PqDatabaseBrowser in the Tools section. This recognised the database, opened it and displayed all the keys correctly. However, clicking on any key gave the same PqFetchError. Does anyone have any idea of what I have done wrong? Thanks for any help. Peter Kenny

Sept. 5, 2016

PunQlite problems

by PBKResearch

Hello I am using Moose 6.0 (Pharo 5.0 Latest update: #50761) on Windows 10. I have installed PunQLite following the instructions in https://github.com/mumez/PunQLite. I have run all the examples that involve using files, and everything seems OK. I have tried creating a database using my own data, which seemed to run OK. The database will display its keys successfully, but whenever I try to retrieve a value I get PqFetchError. The debug information shows that an ffi fetch operation has given a return value of -10. I have searched for any information on unQLite return codes, but so far I have nothing. I tried the PqDatabaseBrowser in the Tools section. This recognised the database, opened it and displayed all the keys correctly. However, clicking on any key gave the same PqFetchError. Does anyone have any idea of what I have done wrong? Thanks for any help. Peter Kenny

Sept. 5, 2016

Re: [Pharo-users] difficult to kill objects - pesky hanging pointersTo

by Andres Valloud

So why doesn't two-way become: help, e.g. ClassOfObjectsThatMustDie allInstances first become: String new As soon as that do-it unwinds there won't be any references to what the new string became (the new string wasn't referenced further), so... On 9/5/16 8:50 , Ben Coman wrote: > Sometimes its *really* hard to kill some objects. It seems that > inspecting a list of pointersTo creates additional hanging references. > This was frustrating me just now, so I finally hacked a way forward. > Sharing it in case its useful to others, and also I can find it again > searching the list. This needs to run for each object. > > Smalltalk garbageCollect. > target := ClassOfObjectsThatMustDie allInstances first. > SystemNavigation default allObjectsDo: [ :e | > (e isKindOf: Association) ifTrue: [ e value = target ifTrue: [ e > value: nil ] ]. > (e isKindOf: Array) ifTrue: [ 1 to: e size do: [ :i | (e at: i) = > target ifTrue: [ e at: i put: nil ] ] ] > ]. > target := nil. > Smalltalk garbageCollect. > > cheers -ben > >

Sept. 5, 2016

Re: [Pharo-users] MNU PPContext>>identifier in GT Inspector extension

by Alistair Grant

Hi Doru, On Thu, Sep 01, 2016 at 11:51:21AM +0200, Tudor Girba wrote: > Hi, > > I just tried it, and I cannot reproduce the problem. > > Here is the exact script: > http://ws.stfx.eu/KC3BLPA3U0FS > (just paste this in Spotter) I can reproduce the problem with the stable release of Pillar, but not with the development or bleeding edge versions. I swear I tried them before, but... :-( Thanks very much for following up and my apologies for the noise. Cheers, Alistair

Sept. 5, 2016

Re: [Pharo-users] Commit to Monticello from the code browser

by stepharo

http://mooc.pharo.org points to all video That are archived on a specific file server http://rmod..... Stef Le 5/9/16 Ã 15:52, Federico.Balaguer a Ã©crit : > Dear Stef > > Do not get me wrong. I really appreciate the effort you guys dedicated to > MOOC and I also appreciate the value of the material. > > My comment came from the fact that I Google for it and I didn't found the > link you just share with me. I will pass it to my students so they can watch > that as well. > > Federico > > > > -- > View this message in context: http://forum.world.st/Commit-to-Monticello-from-the-code-browser-tp4913844p… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Sept. 5, 2016

Re: [Pharo-users] NeoCSV: Interdependent Field

by Sven Van Caekenberghe

> On 05 Sep 2016, at 18:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> Could you write your #title accessor then as > > That's what I ended up doing :) OK. > I just wondered if there was a better way. > Thinking out loud, is there any harm in the added flexibility of passing the > object-in-progress as well as the string to the converter via #cull:cull:? I guess it would be slower. > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/NeoCSV-Interdependent-Field-tp4914190p4914206.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 5, 2016

Re: [Pharo-users] NeoCSV: Interdependent Field

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Could you write your #title accessor then as That's what I ended up doing :) I just wondered if there was a better way. Thinking out loud, is there any harm in the added flexibility of passing the object-in-progress as well as the string to the converter via #cull:cull:? ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoCSV-Interdependent-Field-tp4914190p4914206.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 5, 2016

Re: [Pharo-users] NeoCSV: Interdependent Field

by Sven Van Caekenberghe

> On 05 Sep 2016, at 18:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> Could you elaborate a bit on the concrete use case (or a similar example) >> ? > > Sure. Say the data rows are events which contain, among other things, the > following fields: > -a date > - an employeeID > - a title (as in position in the company e.g. CEO). > > Usually, the title is filled in, but sometimes it's missing. When it's > missing, it can be calculated by `(employees detectID: employeeID) titleOn: > timestamp`*, but if it's present, you should just use the value in the field > because the lookup is inconsistent and expensive. > > Thanks for following up! > > * The timestamp is necessary because you're actually searching through the > employment history to see the title on that particular date in the past. Could you write your #title accessor then as title ^ title ifNil: [ title := (employees detectID: employeeID) titleOn: timestamp ] ? Or do you then again have problems with the #emptyFieldValue: from your previous issue ?

Sept. 5, 2016

Re: [Pharo-users] NeoCSV: Interdependent Field

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Could you elaborate a bit on the concrete use case (or a similar example) > ? Sure. Say the data rows are events which contain, among other things, the following fields: -a date - an employeeID - a title (as in position in the company e.g. CEO). Usually, the title is filled in, but sometimes it's missing. When it's missing, it can be calculated by `(employees detectID: employeeID) titleOn: timestamp`*, but if it's present, you should just use the value in the field because the lookup is inconsistent and expensive. Thanks for following up! * The timestamp is necessary because you're actually searching through the employment history to see the title on that particular date in the past. ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoCSV-Interdependent-Field-tp4914190p4914200.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 5, 2016

Re: [Pharo-users] NeoCSV: Interdependent Field

by Sven Van Caekenberghe

Hi Sean, Could you elaborate a bit on the concrete use case (or a similar example) ? My first response would be to add some intelligence inside your objects. Say you have a person object, setting the first name would set the initial too, unless it was already set, and it could be overwritten later on. Sven PS: I did see you other remark, and I looked at it, but I did not yet reply. > On 05 Sep 2016, at 16:36, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > How (if at all) can one handle parsing when fields depend on one another? It > seems that it would be helpful to have access to the currently constructed > object in field converters, but it doesn't look like that is possible... > > Thanks! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/NeoCSV-Interdependent-Field-tp4914190.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 5, 2016