- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Error While Browsing

by Yuriy Tymchuk

Good to know. This shouldnât happen in the latest pharo 6, I will also back port the solution to pharo 5 > On 18 Jun 2016, at 18:06, Max Leske <maxleske(a)gmail.com> wrote: > > Thatâs about critiques (ccâing Yuriy). > > >> On 18 Jun 2016, at 15:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> This happened when I scrolled to the selected menu in Nautilus... >> >> <http://forum.world.st/file/n4901675/Screenshot_2016-06-18_10.png> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Error-While-Browsing-tp4901675.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

June 18, 2016

AthensCairoSurface not getting garbage collected

by J.F. Rick

I'm using Athens rendering for my multi-touch applications on Pharo5. As part of that, I create a surface: surface := AthensCairoSurface extent: bounds extent asIntegerPoint. Though the object creating that surface is deleted, the surface sticks around. So, each time I run the app, I get another instance of AthensCairoSurface hanging around. That means all the forms stick around as well. So my image can quickly grow towards the 1GB size. Is there anything I can do about that? Can I manually get the surface to delete itself? Cheers, Jeff

June 18, 2016

Re: [Pharo-dev] Pharo 5.0 Tiny Feature Request

by Max Leske

Why donât you use OSSubprocess? Cheers, Max > On 18 Jun 2016, at 16:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I know our policy is to only backport severe bug fixes, but I have one method > I'd like added to 5.0 which would make my life a lot easier. Since > NBMacShell has been removed, there doesn't seem to be a built-in way to send > simple shell commands, which has broken all my project/image load scripts. I > propose the following addition which will restore that basic functionality: > > LibC class>>system: command > ^ self ffiCall: #(#int #system #(#char #* #command)) module: self > > It doesn't change any existing behavior, so seems relatively risk-free. What > do you think? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 18, 2016

Re: [Pharo-dev] Error While Browsing

by Max Leske

Thatâs about critiques (ccâing Yuriy). > On 18 Jun 2016, at 15:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > This happened when I scrolled to the selected menu in Nautilus... > > <http://forum.world.st/file/n4901675/Screenshot_2016-06-18_10.png> > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Error-While-Browsing-tp4901675.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 18, 2016

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

by Ben Coman

Try 50760 from... http://files.pharo.org/image/50/ cheers -ben On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer <petr.fischer(a)me.com> wrote: > 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 18, 2016

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

by Ben Coman

On Sat, Jun 18, 2016 at 12:20 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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? I like this, to further minimise hard coding of alt, & ctrl. Yet there are probably a small number of shortcuts with cross platform conflicts where hardcoded values are still required, and for those it even be useful to hardcode AltException & CtrlException rather than Alt & Ctrl - to make this clear to anyone using the system code as an example - but maybe that would be taking it too far. cheers - > > 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 18, 2016

Pharo 5.0 Tiny Feature Request

by Sean P. DeNigris

I know our policy is to only backport severe bug fixes, but I have one method I'd like added to 5.0 which would make my life a lot easier. Since NBMacShell has been removed, there doesn't seem to be a built-in way to send simple shell commands, which has broken all my project/image load scripts. I propose the following addition which will restore that basic functionality: LibC class>>system: command ^ self ffiCall: #(#int #system #(#char #* #command)) module: self It doesn't change any existing behavior, so seems relatively risk-free. What do you think? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-5-0-Tiny-Feature-Request-tp4901682.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 18, 2016

Error While Browsing

by Sean P. DeNigris

This happened when I scrolled to the selected menu in Nautilus... <http://forum.world.st/file/n4901675/Screenshot_2016-06-18_10.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/Error-While-Browsing-tp4901675.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 18, 2016

PharoLauncher Hanging

by Sean P. DeNigris

I just had Launcher hang (Mac's spinning beach ball of death) twice in a row after launching a 5.0 image with "quit on launch" disabled. Let me know if you need any other information. OS X 10.10.5 Image ----- Pharo5.0 Latest update: #50760 Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 ----- Cheers, Sean -- View this message in context: http://forum.world.st/PharoLauncher-Hanging-tp4901674.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 18, 2016

Re: [Pharo-dev] Better #haltOnce: per haltOnce state, auto-enable

by Marcus Denker

> On 18 Jun 2016, at 06:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Marcus, >> >> >> Marcus >> >> Yes, but using the byte code pc is a much much cheaper key, and just as unique. >> > > But why would I care to make this efficient? Itâs a debug featureâ¦ > > And doing it on the AST is very nice for other reasons, e.g. as I next step I will > add icons in the Editor for all the halt sends. For haltOnce, this will show the state > and toggle the haltOnce to be âonâ again. So, first version (to be improved)â¦ could this be implemented in term of byte code offset. Of course. Would it be nice? I doubt.

June 18, 2016