March 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo 4 - current state?

by Marcus Denker

> On 16 Mar 2015, at 17:41, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> wrote: > > Thanks for your tutorials Kilion. They're very valuable. Talking about Pharo 4, I have downloaded and play a little with it, but I feel it lacks two features that are important to me: > > 1. Proper tab-autocompletion: it works, but feels unresponsive compared with the one on Pharo 3. > > 2. Control arrow key to move between words. > > I imagine that this features will be implemented in the final release. By the way, Â¿when it is planed, mid April? > No, as right now there are no issues reported related to them. (sometimes I really wonderâ¦.) Marcus

March 16, 2015

Re: [Pharo-users] VM Crash

by Franck Warlouzet

Hello, I tried to reproduce this bug, I have also an error with the same configuration. I don't have his problem, however when I quit Pharo, the connection shutdown makes Pharo crashes, but when I only do the connection shutdown, it works. I downloaded the dll here : https://ci.inria.fr/dbxtalk/view/OpenDBX/job/CLibrary-OpenDBX-1.4.6-Mysql/P… Cheers, Franck WARLOUZET Date: Sat, 14 Mar 2015 11:56:00 -0700 From: ml-node+s1294792n4811903h64(a)n4.nabble.com To: franck.warlouzet(a)hotmail.fr Subject: VM Crash Hello, My VM crashes every time I open it. I ran the scripts below before crash occurs. | settings platform connection | settings := DBXConnectionSettings host: 'localhost' port: '3306' database: 'mysql' userName: 'root' userPassword: ''. platform := DBXMySQLBackend new. connection := DBXConnection platform: platform settings: settings. connection connect. connection open. I'm using: - Windows 8.1- OpenDBX dll files.- mysql-connector-c-6.1.5-win32- mysql 5.6.21- Pharo 3.0- OpenDBX driver stable package. I also attached the error pop-up and crash dump, please check. I'm looking forward for your advices. Best regards,Nico -- You received this message because you are subscribed to the Google Groups "DBXTalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. error.PNG (12K) Download Attachment crash.dmp (197K) Download Attachment If you reply to this email, your message will be added to the discussion below: http://forum.world.st/VM-Crash-tp4811903.html To start a new topic under DBXTalk, email ml-node+s1294792n3718169h10(a)n4.nabble.com To unsubscribe from DBXTalk, click here. NAML

March 16, 2015

[Pharo News] Pharo Sprints

by Jean-Christophe Bach

Hello, Pharo sprints are now planned: http://pharo.org/news/Pharo-Sprints The next sprint will be on Friday, 3rd April, at Inria Lille. -- Jean-Christophe Bach

March 16, 2015

Re: [Pharo-users] Fwd: when iterating over a collection how to determine the current objects index

by jtuchel＠objektfabrik.de

Nicolai, I think you are comparing apples and oranges here. AFAIK with:do: uses a second collection as first parameter and iterates over both of them. That's a completely different meaning of "with", imo. Let's not get started on the many ways in which with:do: is badly named ;-) I agree we can end this discussion as it is. I have two main arguments against renaming doWithIndex: one of which is that it would make Pharo just a little more incompatible with other dialects and one based on my guts about the name itself. This will not lead anywhere ;-) Joachim Am 16.03.15 um 13:41 schrieb Nicolai Hess: > > ---------- Forwarded message ---------- > From: *Nicolai Hess* <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> > Date: 2015-03-16 13:40 GMT+01:00 > Subject: Re: [Pharo-users] when iterating over a collection how to > determine the current objects index > To: "jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>" > <jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de>> > > > > 2015-03-16 12:19 GMT+01:00 jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de> <jtuchel(a)objektfabrik.de > <mailto:jtuchel@objektfabrik.de>>: > > Nicolai, > > > > > > Am 16.03.15 um 11:59 schrieb Nicolai Hess: >> >> 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris >> <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: >> >> Marcus Denker-4 wrote >> > which version do we pick? We should pick one, rename the callers >> >> As someone mentioned earlier in the thread, #doWithIndex: has >> the advantage >> of mirroring the argument order (although this still should >> be documented), >> and it's the one most people are probably most familiar with, >> so IMHO it >> makes sense to standardize on that. >> >> >> I like withIndexDo: because code like >> > so how would you name the current #do: if you had the choice? > > I still think this looks very logical: > > #do: > #do:separatedBy: > #doWithIndex: > #doWithSomeOtherSpecialty:andEvenMoreStuff: > > And then there still ist the question if the order of the > arguments should be changed: > > today: > > do: [:each| ] > doWithIndex: [:each :index| ] > > future: > > do: [:each| ] > withIndexDo: [:idx :each | ] > > Do you really think that is better? > > I think that if we move the withIndex part to the beginning of the > message, it overstates the importance of the fact that we also > need the index inside the iteration block. > > > >> aCollection withIndexDo: aBlock >> reads like >> "a collection with index" do >> > This would make sense if it was a Collection with an Index. > > > no, that is the point. > A collection with no index: > aCollection do: > > A collection with no index, but iterator over it like it had one: > aCollection withIndex do: > > From the method comment: > withIndexDo: elementAndIndexBlock > "Just like with:do: except that the iteration index supplies the > second argument to the block." > > it looks like this method derives from : > > SequenceableCollection>>#with: otherCollection do: twoArgBlock > "Evaluate twoArgBlock with corresponding elements from this > collection and otherCollection." > > > > > If there was an IndexedCollection class and maybe some message > like asIndexedCollection or withIndex, which turns any collection > into an IndexedCollection. Then the message might be a shortcut > for "make thsi an indexed collection and iterate over it using its > index" - comparable to Dictionary>>#keysAndValuesDo: - but please > be aware that a Dictionary has keys and values by its very own > nature. A Collection doesn't have an index (other than the fact > that the elements are stored in some non-guarantueed order). > > > This may all sound quite picky, but I think this is plain wrong > and you are about to introduce not only incompatible, but also > misleading naming for methods that exist on all Smalltalk dialects. > > > > I don't want to rename it, it is already there. I just said I like the > one better than the other one. > But it is not really important, I am fine with either or both. This > was just my explanation why I would choose withIndexDo: > > > Joachim > >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… >> Sent from the Pharo Smalltalk Users mailing list archive at >> Nabble.com. >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de > Fliederweg 1http://www.objektfabrik.de > D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 16, 2015

Fwd: when iterating over a collection how to determine the current objects index

by Nicolai Hess

---------- Forwarded message ---------- From: Nicolai Hess <nicolaihess(a)web.de> Date: 2015-03-16 13:40 GMT+01:00 Subject: Re: [Pharo-users] when iterating over a collection how to determine the current objects index To: "jtuchel(a)objektfabrik.de" <jtuchel(a)objektfabrik.de> 2015-03-16 12:19 GMT+01:00 jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> : > Nicolai, > > > > > > Am 16.03.15 um 11:59 schrieb Nicolai Hess: > > > 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Marcus Denker-4 wrote >> > which version do we pick? We should pick one, rename the callers >> >> As someone mentioned earlier in the thread, #doWithIndex: has the >> advantage >> of mirroring the argument order (although this still should be >> documented), >> and it's the one most people are probably most familiar with, so IMHO it >> makes sense to standardize on that. >> > > I like withIndexDo: because code like > > so how would you name the current #do: if you had the choice? > > I still think this looks very logical: > > #do: > #do:separatedBy: > #doWithIndex: > #doWithSomeOtherSpecialty:andEvenMoreStuff: > > And then there still ist the question if the order of the arguments should > be changed: > > today: > > do: [:each| ] > doWithIndex: [:each :index| ] > > future: > > do: [:each| ] > withIndexDo: [:idx :each | ] > > Do you really think that is better? > > I think that if we move the withIndex part to the beginning of the > message, it overstates the importance of the fact that we also need the > index inside the iteration block. > > > > aCollection withIndexDo: aBlock > reads like > "a collection with index" do > > This would make sense if it was a Collection with an Index. > no, that is the point. A collection with no index: aCollection do: A collection with no index, but iterator over it like it had one: aCollection withIndex do: >From the method comment: withIndexDo: elementAndIndexBlock "Just like with:do: except that the iteration index supplies the second argument to the block." it looks like this method derives from : SequenceableCollection>>#with: otherCollection do: twoArgBlock "Evaluate twoArgBlock with corresponding elements from this collection and otherCollection." > If there was an IndexedCollection class and maybe some message like > asIndexedCollection or withIndex, which turns any collection into an > IndexedCollection. Then the message might be a shortcut for "make thsi an > indexed collection and iterate over it using its index" - comparable to > Dictionary>>#keysAndValuesDo: - but please be aware that a Dictionary has > keys and values by its very own nature. A Collection doesn't have an index > (other than the fact that the elements are stored in some non-guarantueed > order). > > > This may all sound quite picky, but I think this is plain wrong and you > are about to introduce not only incompatible, but also misleading naming > for methods that exist on all Smalltalk dialects. > I don't want to rename it, it is already there. I just said I like the one better than the other one. But it is not really important, I am fine with either or both. This was just my explanation why I would choose withIndexDo: > > Joachim > > > > > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel(a)objektfabrik.de> > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

March 16, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Werner Kassens

Hi, there are several methods that end with withBlaBla: aBlabla (ok, they have generally several arguments). hence i would expect doWithIndex: to have this form #doWithIndex: anIndex. and anything that ends with do: expects a doBlock and several methods that have the form doSomething: dont expect a block as argument. iow i find withIndexDo: more logical than doWithIndex: werner

March 16, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by jtuchel＠objektfabrik.de

Nicolai, Am 16.03.15 um 11:59 schrieb Nicolai Hess: > > 2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>>: > > Marcus Denker-4 wrote > > which version do we pick? We should pick one, rename the callers > > As someone mentioned earlier in the thread, #doWithIndex: has the > advantage > of mirroring the argument order (although this still should be > documented), > and it's the one most people are probably most familiar with, so > IMHO it > makes sense to standardize on that. > > > I like withIndexDo: because code like > so how would you name the current #do: if you had the choice? I still think this looks very logical: #do: #do:separatedBy: #doWithIndex: #doWithSomeOtherSpecialty:andEvenMoreStuff: And then there still ist the question if the order of the arguments should be changed: today: do: [:each| ] doWithIndex: [:each :index| ] future: do: [:each| ] withIndexDo: [:idx :each | ] Do you really think that is better? I think that if we move the withIndex part to the beginning of the message, it overstates the importance of the fact that we also need the index inside the iteration block. > aCollection withIndexDo: aBlock > reads like > "a collection with index" do > This would make sense if it was a Collection with an Index. If there was an IndexedCollection class and maybe some message like asIndexedCollection or withIndex, which turns any collection into an IndexedCollection. Then the message might be a shortcut for "make thsi an indexed collection and iterate over it using its index" - comparable to Dictionary>>#keysAndValuesDo: - but please be aware that a Dictionary has keys and values by its very own nature. A Collection doesn't have an index (other than the fact that the elements are stored in some non-guarantueed order). This may all sound quite picky, but I think this is plain wrong and you are about to introduce not only incompatible, but also misleading naming for methods that exist on all Smalltalk dialects. Joachim > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

March 16, 2015

Re: [Pharo-users] when iterating over a collection how to determine the current objects index

by Nicolai Hess

2015-03-14 11:55 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Marcus Denker-4 wrote > > which version do we pick? We should pick one, rename the callers > > As someone mentioned earlier in the thread, #doWithIndex: has the advantage > of mirroring the argument order (although this still should be documented), > and it's the one most people are probably most familiar with, so IMHO it > makes sense to standardize on that. > I like withIndexDo: because code like aCollection withIndexDo: aBlock reads like "a collection with index" do > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/when-iterating-over-a-collection-how-to-determine-the… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

March 16, 2015

Re: [Pharo-users] Error while loading GitFileTree in Pharo 4.0

by Jigyasa Grover

The 'missing' files are present in the zip folder , but they arent in the github-cache folder from where the Pharo is accessing it On Mon, Mar 16, 2015 at 2:51 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Can you check if the missing file is present in the zip, and in the > decompressed part on disk? > > Note that we are dealing with a Metacello/FileTree error, not a > GitFileTree one. > > Thierry > > 2015-03-16 9:56 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > >> Yes Sir. >> I have checked 'em all. >> >> [image: Inline image 2][image: Inline image 1][image: Inline image 4][image: >> Inline image 3] >> >> On Mon, Mar 16, 2015 at 2:22 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> This is strange. >>> >>> I tried both the Gofer and the Metacello script before replying to you, >>> and they both worked. >>> >>> Do you have a file named >>> github-dalehenrichfiletreepharo40dev<number>.zip in your pharo repository? >>> Do you have a directory named >>> >>> >>> github-cache/dalehenrich/filetree/pharo4.0_dev/dalehenrich-filetree-7f998e5 >>> >>> Thierry >>> >>> 2015-03-16 9:43 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >>> >>>> Sir >>>> I have cleared the previous files and tried to load directly from >>>> github as directed by you. >>>> The error still persists. There are missing files again. >>>> >>>> Thanks >>>> Jigyasa Grover >>>> >>>> On Mon, Mar 16, 2015 at 2:07 PM, Thierry Goubier < >>>> thierry.goubier(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> an alternative solution is to load directly from github, with: >>>>> >>>>> Metacello new >>>>> baseline: 'FileTree'; >>>>> repository: 'github://dalehenrich/filetree:pharo4.0_dev/repository'; >>>>> load: 'Git' >>>>> >>>>> Missing files may mean a leftover from a previous, failed load attempt. >>>>> >>>>> Thierry >>>>> >>>>> 2015-03-16 8:19 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >>>>> >>>>>> Thanks! >>>>>> >>>>>> The error now says = File missing : >>>>>> ..\repository\MonticelloFileTree-Git.package\monticello.meta\version >>>>>> >>>>>> What is the way out ? >>>>>> >>>>>> >>>>> >>>> >>> >> >

March 16, 2015

Re: [Pharo-users] Error while loading GitFileTree in Pharo 4.0

by Thierry Goubier

Can you check if the missing file is present in the zip, and in the decompressed part on disk? Note that we are dealing with a Metacello/FileTree error, not a GitFileTree one. Thierry 2015-03-16 9:56 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > Yes Sir. > I have checked 'em all. > > [image: Inline image 2][image: Inline image 1][image: Inline image 4][image: > Inline image 3] > > On Mon, Mar 16, 2015 at 2:22 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> This is strange. >> >> I tried both the Gofer and the Metacello script before replying to you, >> and they both worked. >> >> Do you have a file named github-dalehenrichfiletreepharo40dev<number>.zip >> in your pharo repository? Do you have a directory named >> >> >> github-cache/dalehenrich/filetree/pharo4.0_dev/dalehenrich-filetree-7f998e5 >> >> Thierry >> >> 2015-03-16 9:43 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >> >>> Sir >>> I have cleared the previous files and tried to load directly from github >>> as directed by you. >>> The error still persists. There are missing files again. >>> >>> Thanks >>> Jigyasa Grover >>> >>> On Mon, Mar 16, 2015 at 2:07 PM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> an alternative solution is to load directly from github, with: >>>> >>>> Metacello new >>>> baseline: 'FileTree'; >>>> repository: 'github://dalehenrich/filetree:pharo4.0_dev/repository'; >>>> load: 'Git' >>>> >>>> Missing files may mean a leftover from a previous, failed load attempt. >>>> >>>> Thierry >>>> >>>> 2015-03-16 8:19 GMT+01:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >>>> >>>>> Thanks! >>>>> >>>>> The error now says = File missing : >>>>> ..\repository\MonticelloFileTree-Git.package\monticello.meta\version >>>>> >>>>> What is the way out ? >>>>> >>>>> >>>> >>> >> >

March 16, 2015