June 2016 - Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60093 Home: https://github.com/pharo-project/pharo-core

June 17, 2016

[pharo-project/pharo-core] 285ba2: 60093

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 285ba25d0f135d01939d408071264306d3818728 https://github.com/pharo-project/pharo-core/commit/285ba25d0f135d01939d4080… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-17 (Fri, 17 Jun 2016) Changed paths: R Collections-Abstract.package/Collection.class/instance/testing/ifEmpty_ifNotEmptyDo_.st R Collections-Abstract.package/Collection.class/instance/testing/ifNotEmptyDo_.st R Collections-Abstract.package/Collection.class/instance/testing/ifNotEmptyDo_ifEmpty_.st A Deprecated60.package/extension/Collection/instance/ifEmpty_ifNotEmptyDo_.st A Deprecated60.package/extension/Collection/instance/ifNotEmptyDo_.st A Deprecated60.package/extension/Collection/instance/ifNotEmptyDo_ifEmpty_.st A Deprecated60.package/extension/Object/instance/ifNil_ifNotNilDo_.st A Deprecated60.package/extension/Object/instance/ifNotNilDo_.st A Deprecated60.package/extension/Object/instance/ifNotNilDo_ifNil_.st M Kernel-Tests.package/ObjectTest.class/instance/tests - debugging/testHaltOnCount.st R Kernel.package/Object.class/instance/nil testing/ifNil_ifNotNilDo_.st R Kernel.package/Object.class/instance/nil testing/ifNotNilDo_.st R Kernel.package/Object.class/instance/nil testing/ifNotNilDo_ifNil_.st R Kernel.package/UndefinedObject.class/instance/testing/ifNotNilDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60092.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60093.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60092.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60093.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60093 18512 cleanup related to deprecations https://pharo.fogbugz.com/f/cases/18512 http://files.pharo.org/image/60/60093.zip

June 17, 2016

Re: [Pharo-dev] Official packages on pharo.com - broken

by Jan Vrany

On Fri, Jun 17, 2016 at 2:56 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Jun 17, 2016 at 03:24:37PM +0200, Sven Van Caekenberghe wrote: >> >> > On 17 Jun 2016, at 15:15, Petr Fischer <petr.fischer(a)me.com> >> wrote: >> > >> > It's due to my obscure OS (âFreeBSD, latest). They have Linux >> compatibility (even 64bits soon), so it's nice, but libs are from >> CentOS6 (now) with glibc 2.12 etc etc. >> > >> > But disfunct downloads on pharo.org is bad. âRemoving obsolete >> thinks from official website is not bad idea. >> >> It is not dysfunctional, it is legacy, that is important too. > > It is dysfunctional in the sense that it claims it's for Pharo 5, > which is no longer true since December (or whenever we've switched to > Spur). > > The action should be either: > > a) remove the link altogher > b) say that it's only for Pharo 4 (if you want to support legacy) > > In addition to that, if you want backward compatiblity (legacy > argument here imho fails, because Pharo 5 has been released a month > ago) > > 1) build spur with glibc <2.15 and add it as a download for Pharo 5 There is such a VM: https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/ in case you need it. Jan > > > I think there's no point in doing this as you are just increasing > maintenance/legacy burden down the road, but I wouldn't be the one > doing that so that's not my call. > > Peter >

June 17, 2016

Re: [Pharo-dev] Official packages on pharo.com - broken

by Peter Uhnak

On Fri, Jun 17, 2016 at 03:24:37PM +0200, Sven Van Caekenberghe wrote: > > > On 17 Jun 2016, at 15:15, Petr Fischer <petr.fischer(a)me.com> wrote: > > > > It's due to my obscure OS (âFreeBSD, latest). They have Linux compatibility (even 64bits soon), so it's nice, but libs are from CentOS6 (now) with glibc 2.12 etc etc. > > > > But disfunct downloads on pharo.org is bad. âRemoving obsolete thinks from official website is not bad idea. > > It is not dysfunctional, it is legacy, that is important too. It is dysfunctional in the sense that it claims it's for Pharo 5, which is no longer true since December (or whenever we've switched to Spur). The action should be either: a) remove the link altogher b) say that it's only for Pharo 4 (if you want to support legacy) In addition to that, if you want backward compatiblity (legacy argument here imho fails, because Pharo 5 has been released a month ago) 1) build spur with glibc <2.15 and add it as a download for Pharo 5 I think there's no point in doing this as you are just increasing maintenance/legacy burden down the road, but I wouldn't be the one doing that so that's not my call. Peter

June 17, 2016

Re: [Pharo-dev] Official packages on pharo.com - broken

by Sven Van Caekenberghe

> On 17 Jun 2016, at 15:15, Petr Fischer <petr.fischer(a)me.com> wrote: > > It's due to my obscure OS (âFreeBSD, latest). They have Linux compatibility (even 64bits soon), so it's nice, but libs are from CentOS6 (now) with glibc 2.12 etc etc. > > But disfunct downloads on pharo.org is bad. âRemoving obsolete thinks from official website is not bad idea. It is not dysfunctional, it is legacy, that is important too. If you want us to drop our own older releases, than we should also drop old/weird linux versions ;-) But of course, it should be better described to avoid the confusion. > My next step is to compile VM myself directly on BSD with clang (and 64bit fast spur soon!), but it's too big step for me now. > > Thanks to all, rething the download section on Pharo website, or fix builds... pf > > Od: Peter UhnÃ¡k > OdeslÃ¡no: pÃ¡tek, 17. Äervna 2016 14:46 > Komu: Pharo Development List > OdpovÄdÄt: Pharo Development List > PÅedmÄt: Re: [Pharo-dev] Official packages on pharo.com - broken > > I guess nobody would expect that you would such an old setup with new Pharo? > > Maybe it should be removed altogether? Why are people using four years old libraries with the latest Pharo? > > On Fri, Jun 17, 2016 at 1:18 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > Hello, > > look at this page: > http://pharo.org/gnu-linux-installation > > and try to download "libc < 2.15" or "centos" versions. > Both are broken - error message immediately after start: > > "This interpreter (vers. 6505) cannot read image file (vers. 6521)." > > So, the first impression is really terrible (don't work at all). > Default GNU/Linux download is probably OK. > > pf > > >

June 17, 2016

Re: [Pharo-dev] Official packages on pharo.com - broken

by Petr Fischer

June 17, 2016

[pharo-project/pharo-core] d6d2a4: 60092

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d6d2a49d685a98a1bdebbd9c76b046c06acfc2bd https://github.com/pharo-project/pharo-core/commit/d6d2a49d685a98a1bdebbd9c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-17 (Fri, 17 Jun 2016) Changed paths: M Kernel-Tests.package/ObjectTest.class/instance/tests - debugging/testHaltOnCount.st M Kernel-Tests.package/ObjectTest.class/instance/tests - debugging/testHaltOnce.st R Kernel.package/Halt.class/class/class initialization/initialize.st R Kernel.package/Halt.class/class/halting/ifShiftPressed.st M Kernel.package/Halt.class/class/halting/onCount_.st M Kernel.package/Halt.class/class/halting/once.st R Kernel.package/Halt.class/class/once-enabling%2Fdisabling/enableHaltOnce.st A Kernel.package/Halt.class/class/once-reset/resetHaltOnce.st R Kernel.package/Halt.class/class/private/callsUntilHaltOnCount.st R Kernel.package/Halt.class/class/private/callsUntilHaltOnCount_.st R Kernel.package/Halt.class/class/private/isCounting.st R Kernel.package/Halt.class/class/private/stopCounting.st M Morphic-Base.package/extension/WorldState/class/systemOn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60091.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60092.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60091.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60092.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60092 18509 per send-site #haltOnCount: https://pharo.fogbugz.com/f/cases/18509 http://files.pharo.org/image/60/60092.zip

June 17, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60092 Home: https://github.com/pharo-project/pharo-core

June 17, 2016

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

by Nicolai Hess

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") > 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 ? > > 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