- Pharo-dev - lists.pharo.org

ReÂ : Re: [Pharo-users] Pharo Launcher

by Christophe Demarey

Yes. It was that. Thanks ----- Sean P. DeNigris <sean(a)clipperadams.com> a Ã©critÂ : > demarey wrote > > Now fixed > > Was that due to the #vm40Path being incorrectly set? I was going to report > that... > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-Launcher-tp4901336p4901477.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 17, 2016

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

by Petr Fischer

VM version (from https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/) 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 https://github.com/estebanlm/pharo-vm.git Commit: 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] Image version (from official 5.0 download): [version] 5.0 #50723 pf > in fact, this is not related to FFIâ¦ but it should be fixedâ¦ > > along with the VM version, which version of Pharo are you using? > > Esteban > > > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> wrote: > > > > Hi Petr, > > > > That looks like a bug with FreeType with our FFI. It should actually have been fixed but I donât know if the VM for FreeBSD is up to date. Can you post the output of âSmalltalk vm versionâ? > > > > Cheers, > > Max > > > >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> wrote: > >> > >> Hello, I got some random segfaults (while loading Seaside) with 32 bit spur vm on FreeBSD - can someone (with low level knowledge) decode attached log? > >> Is this some problem with stack size? Can I fix this? > >> > >> Log: > >> http://pastebin.com/raw/NpFUnjh0 > >> > >> There is "**StackOverflow**" lines n the log... > >> > >> Thanks! pf > >> > > > > > >

June 17, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

Hi Nicolai, > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Nicolai, > > I am a bit removed from the code details at the moment, and I think I need to step back a bit :). > > If I understand correctly, you are saying that: > 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here. > > As far as I know, this is on purpose. A key pressed with windows (left) alt modified is mapped to "command" > > from vm source: > > * 3) The modifier keys are mapped as follows: > * > * Mac | Win32 > * -------------------- > * Shift -> Shift > * Ctrl -> Ctrl > * Command -> Left ALT > * Option -> Right ALT > > (but actually, the right ALT key does not generate any keystrokes (only key down/up) and it is treated as ctrl+alt (windows right Alt key is "Alt Grâ) Hmm. I think we have to rethink this one because we need two layers of keys: 1. first we should have the raw ones, and 2. another layer that offers a more logical keys (like meta). What do you think? > 2. defining the > bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt. > > using alt+right on windows/linux and > command + right on mac > for dive-in or for text navigation? > > Is there a default keycombination for word-moving in text components for mac ? On Mac, typically Alt+Right/Left moves between words. So, we would need a logical modifier that would mean: - Mac: Alt - Win: Ctrl - Linux: Ctrl What do you think? Cheers, Doru > > Does this make sense? > > Cheers, > Doru > > > > On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. > > > > On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter > > because spotter redefines this keystrokes for dive in /out. > > Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher > > explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. > > (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). > > > > > > The idea was to offer a uniform support of keybindings in Pharo, in general. > > > > exactly, and using ctrl+left/right uniformly in editor and external tools would be great. > > > > Then Guille etal added #meta to have a predictable mapping. > > > > Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this > > if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) > > > > All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta. > > > > At this point, both Rubric and Spotter use #meta. #meta maps on: > > - Mac: Command > > - Win: Control > > - Linus: Control > > > > This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta. > > > > You can not use #alt modifier on windows. A shortcut definition like > > $g alt > > is never recognized. You have to define it > > $g command > > to make it work with as "alt+g"-keycombination (on windows). > > > > > > > > For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead. > > > > This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo? > > > > Cheers, > > Doru > > > > > > > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > We can, but I remember there were some discussions and it was decided to use meta everywhere. > > > > > > Cheers, > > > Andrei > > > > > > > > > If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. > > > > > > What are the arguments for using meta for dive-in/out shortcuts ? > > > > > > > > > > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > > During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. > > > > > > Cheers, > > > Andrei > > > > > > Can we change this for spotter ? cmd instead of meta > > > > > > ctrl left/right is often used for text components to move to next/previous word. > > > > > > > > > > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard(a)uia.no>: > > > > > > > > IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. > > > > > > > > > No, it changed > > > > > > In #40624, for example, it was cmd (alt-key on windows ) right/shift right > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Henrik > > > > > > > > > > > > > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess > > > > Sent: Tuesday, June 7, 2016 12:56 PM > > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut > > > > > > > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > > > > cmd+right > > > > > > > > cmd+shift+right > > > > > > > > to > > > > > > > > ctrl+right > > > > ctrl+shift+right > > > > > > > > I know there were some discussions about this and that the behavior changed some > > > > > > > > time ago, but I don't know the rational behind this. > > > > > > > > thanks > > > > > > > > nicolai > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "If you interrupt the barber while he is cutting your hair, > > you will end up with a messy haircut." > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

June 17, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

Hi, > On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > #alt_meta ? > - Maps to alt on OSX, ctrl on Win/Linux. > - Can only bind either #meta or #alt_meta + key, or both must bind to same action. > - Can only be applied to a very limited set of keys, (usually those employed in navigation). > (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Thanks for the input! Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt What do you think? Doru > Cheers, > Henry > >> On 17 Jun 2016, at 2:35 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi Nicolai, >> >> I am a bit removed from the code details at the moment, and I think I need to step back a bit :). >> >> If I understand correctly, you are saying that: >> 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here. >> 2. defining the bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt. >> >> Does this make sense? >> >> Cheers, >> Doru >> >> >>> On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. >>> >>> On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter >>> because spotter redefines this keystrokes for dive in /out. >>> Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher >>> explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. >>> (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). >>> >>> >>> The idea was to offer a uniform support of keybindings in Pharo, in general. >>> >>> exactly, and using ctrl+left/right uniformly in editor and external tools would be great. >>> >>> Then Guille etal added #meta to have a predictable mapping. >>> >>> Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this >>> if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) >>> >>> All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta. >>> >>> At this point, both Rubric and Spotter use #meta. #meta maps on: >>> - Mac: Command >>> - Win: Control >>> - Linus: Control >>> >>> This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta. >>> >>> You can not use #alt modifier on windows. A shortcut definition like >>> $g alt >>> is never recognized. You have to define it >>> $g command >>> to make it work with as "alt+g"-keycombination (on windows). >>> >>> >>> >>> For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead. >>> >>> This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo? >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> >>>> 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>>> We can, but I remember there were some discussions and it was decided to use meta everywhere. >>>> >>>> Cheers, >>>> Andrei >>>> >>>> >>>> If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. >>>> >>>> What are the arguments for using meta for dive-in/out shortcuts ? >>>> >>>> >>>> >>>> On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>>> During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. >>>> >>>> Cheers, >>>> Andrei >>>> >>>> Can we change this for spotter ? cmd instead of meta >>>> >>>> ctrl left/right is often used for text components to move to next/previous word. >>>> >>>> >>>> >>>> On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> >>>> 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>> Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard(a)uia.no>: >>>>> >>>>> IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. >>>> >>>> >>>> No, it changed >>>> >>>> In #40624, for example, it was cmd (alt-key on windows ) right/shift right >>>> >>>> >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Henrik >>>>> >>>>> >>>>> >>>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess >>>>> Sent: Tuesday, June 7, 2016 12:56 PM >>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>> Subject: [Pharo-dev] GT-Spotter dive in shortcut >>>>> >>>>> >>>>> >>>>> Why did the shortcut for dive-in element/category changed from >>>>> >>>>> cmd+right >>>>> >>>>> cmd+shift+right >>>>> >>>>> to >>>>> >>>>> ctrl+right >>>>> ctrl+shift+right >>>>> >>>>> I know there were some discussions about this and that the behavior changed some >>>>> >>>>> time ago, but I don't know the rational behind this. >>>>> >>>>> thanks >>>>> >>>>> nicolai >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." >> >> > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

June 17, 2016

Issues with CI Worker

by Yuriy Tymchuk

Hi, there is a project which validates slices and configurations submitted to issue tracker. Lately Iâve discovered a couple of issues and opened cases about them: https://pharo.fogbugz.com/f/cases/18502/ https://pharo.fogbugz.com/f/cases/18499/ Also one of my tests is regularly failing during validation. The test checks if certain singleton is updating itâs cache when a class is removed. For some reason during validation the object is not subscribed to the system announcer any more. I need to know if there is something special happening in the CI worker, I if I need to manage the subscription in a different way. It would be really nice if someone who is familiar with the CI project gave me a hand because it takes plenty of time to understand how it is workingâ¦ Cheers. Uko

June 17, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Henrik Johansen

#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Cheers, Henry > On 17 Jun 2016, at 2:35 , Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Nicolai, > > I am a bit removed from the code details at the moment, and I think I need to step back a bit :). > > If I understand correctly, you are saying that: > 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here. > 2. defining the bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt. > > Does this make sense? > > Cheers, > Doru > > >> On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. >> >> On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter >> because spotter redefines this keystrokes for dive in /out. >> Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher >> explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. >> (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). >> >> >> The idea was to offer a uniform support of keybindings in Pharo, in general. >> >> exactly, and using ctrl+left/right uniformly in editor and external tools would be great. >> >> Then Guille etal added #meta to have a predictable mapping. >> >> Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this >> if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) >> >> All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta. >> >> At this point, both Rubric and Spotter use #meta. #meta maps on: >> - Mac: Command >> - Win: Control >> - Linus: Control >> >> This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta. >> >> You can not use #alt modifier on windows. A shortcut definition like >> $g alt >> is never recognized. You have to define it >> $g command >> to make it work with as "alt+g"-keycombination (on windows). >> >> >> >> For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead. >> >> This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo? >> >> Cheers, >> Doru >> >> >> >>> On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> We can, but I remember there were some discussions and it was decided to use meta everywhere. >>> >>> Cheers, >>> Andrei >>> >>> >>> If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier. >>> >>> What are the arguments for using meta for dive-in/out shortcuts ? >>> >>> >>> >>> On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: >>> During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. >>> >>> Cheers, >>> Andrei >>> >>> Can we change this for spotter ? cmd instead of meta >>> >>> ctrl left/right is often used for text components to move to next/previous word. >>> >>> >>> >>> On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>> Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard(a)uia.no>: >>>> >>>> IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ. >>> >>> >>> No, it changed >>> >>> In #40624, for example, it was cmd (alt-key on windows ) right/shift right >>> >>> >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Henrik >>>> >>>> >>>> >>>> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess >>>> Sent: Tuesday, June 7, 2016 12:56 PM >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> Subject: [Pharo-dev] GT-Spotter dive in shortcut >>>> >>>> >>>> >>>> Why did the shortcut for dive-in element/category changed from >>>> >>>> cmd+right >>>> >>>> cmd+shift+right >>>> >>>> to >>>> >>>> ctrl+right >>>> ctrl+shift+right >>>> >>>> I know there were some discussions about this and that the behavior changed some >>>> >>>> time ago, but I don't know the rational behind this. >>>> >>>> thanks >>>> >>>> nicolai >>>> >>>> >>> >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > >

June 17, 2016

Re: [Pharo-dev] got some bugs in Pharo 50

by Max Leske

Iâve added the example Iâm working on to the issue. Itâs not directly usable as test case but should give the idea of how to write one. Cheers, Max > On 17 Jun 2016, at 16:51, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-17 16:41 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > I found at least one problem the NEC: NEC assumes that all global bindings answer a class but that is not true in cases such as Processor and Transcript. > > Can you give a code example where this would fail / raise an error . We should add a test case for this. > > > > Hereâs a fix: > > NECVarTypeGuesser>>pushLiteralVariable: anAssociation > "Push Contents Of anAssociation On Top Of Stack bytecode." > | info | > contextCount > 0 ifTrue:[^self]. > > info := NECTypeInfo definedByMessageSend: (anAssociation value isBehavior > ifTrue: [ anAssociation value ] > ifFalse: [ anAssociation value class ]). > types add: info > > Issue: https://pharo.fogbugz.com/f/cases/18513/NEC-fails-to-guess-the-type-of-non-… <https://pharo.fogbugz.com/f/cases/18513/NEC-fails-to-guess-the-type-of-non-…> > > Cheers, > Max > > >> On 05 Jun 2016, at 17:44, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> 2016-06-04 20:41 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> Just to report (I did not have the time to check in 60a) but I got red square of death with komitter. >> >> I also got >> >> NECTypedModel>>initializeSelectorsFor: aClass >> |excludedClasses| >> selectors reset. >> excludedClasses := (expanded ifTrue: [#()] ifFalse: [Object withAllSuperclasses]). >> selectors addAll: ((aClass allSelectorsWithout: excludedClasses) >> >> collect: [:each | NECSelectorEntry contents: each type: #selector]) >> >> >> >> DNU on allSelectorsWithout: >> >> >> with such code >> >> >> mostCommonlyUsedSelectors >> "self mostCommonlyUsedSelectors" >> >> | result | >> result := Bag new. >> environment cla >> >> ^ cursor here >> >> do: [ :each | result addAll: each selectors]. >> ^ result sortedCounts >> >> >> Stef >> >> Can not reproduce the NEC- bug. >> What 5.0 image did you use, the release version? >> In what class did you try to add the method mostCommonlyUsedSelectors? >> >> nicolai >> >> >> > >

June 17, 2016

Re: [Pharo-dev] [Pharo-users] Pharo Launcher

by Serge Stinckwich

Thank you Christophe ! Works now. But I have some stability problems, after launching some images, PharoLauncher freeze ... But this is not a new problems. I had the same issue before. Regards On Fri, Jun 17, 2016 at 1:10 PM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > Now fixed. I replaced the DMG on files.pharo.org. > Thanks for the report > >> Le 17 juin 2016 Ã 13:34, Christophe Demarey <christophe.demarey(a)inria.fr> a Ã©crit : >> >>> >>> Le 17 juin 2016 Ã 12:00, Serge Stinckwich <serge.stinckwich(a)gmail.com> a Ã©crit : >>> >>> On Fri, Jun 17, 2016 at 10:22 AM, Christophe Demarey >>> <christophe.demarey(a)inria.fr> wrote: >>>> Hi, >>>> >>>> I just updated Pharo Launcher. A new version 0.2.11 is available. >>>> Here are the change log: >>> >>> Great ! Thank you for the update. >>> >>>> move Pharo Launcher to the latest stable pharo image: pharo 5.0. It implies >>>> That Pharo Launcher is now shipped with Spur VM. >>>> allow an easy download of the new beta image: pharo 6.0 >>>> the Launcher now comes with 2 VMs: >>>> >>>> Spur VM (pharo 5.0 and Pharo 6.0) >>>> Non-Spur VM (to be able to run old images) >>> >>> I dl the mac version. I was not able to run non-spur VM images: the >>> launcher crash or do nothing ... >> >> Indeed, I think itâs a side effect of latest changes I did after testing on Windows. >> I take a look at it now > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 17, 2016

Re: [Pharo-dev] [Pharo-users] Pharo Launcher

by Sean P. DeNigris

demarey wrote > Now fixed Was that due to the #vm40Path being incorrectly set? I was going to report that... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Launcher-tp4901336p4901477.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 17, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Tim Felgentreff

Hi Karl, As soon as there is a build script for one, yes :) cheers, Tim On 17 June 2016 at 15:22, karl ramberg <karlramberg(a)gmail.com> wrote: > Will Win x64 VM be built also ? > > Best, > Karl > > On Wed, Jun 15, 2016 at 7:26 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> >> Hi all, >> >> we are all finished importing the VM repository to Github, migrating the >> scripts, and setting up automatic builds and hosting of binaries. We want >> to switch over from SVN tomorrow morning at 7am UTC. At that point, Tim and >> Fabio will merge any remaining commits on the SVN repository between now and >> that time and any further development will take place on Github. If >> possible, you may refrain from committing to SVN, as this will mean less >> work for Tim and Fabio. >> >> The new repository is at https://github.com/OpenSmalltalk/vm. The Cog >> branch is the new default branch and is still called Cog, this is the main >> focus of development. The old trunk branch has been renamed to "oldTrunk". >> The master branch will track the Cog branch and will be the repository >> integrated into for releases. >> >> To get started, please refer to the updated README that is shown on the >> Github page. >> >> _,,,^..^,,,_ >> best, Eliot, Tim & Fabio >> > > > >

June 17, 2016