January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

by Sven Van Caekenberghe

Yes it is legacy, yes changing it will break things. Now, this is not such an easy topic. I agree that the example given goes way too far (as a general parser), but most parsers will allow junk at the end, as in '100euro'. Often good, sometimes bad. So it depends on the use case. Strict vs lenient. Also, let's not add more methods to String, please. > On 13 Jan 2017, at 10:51, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that. > > Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :). > > On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > I've come across an implementation of #asInteger and #asSignedInteger in > Pharo 3.0 that leaves me scratching my head. > > Can anyone explain why it was defined to answer what it does for strings > that one would really not expect to parse as a number. > > 'abc-123-xyz-897' asSignedInteger > ===> -123 > > To my mind, the method that does this for the example string should have an > intention revealing name like #spelunkIntegerFromString or some such. > > > Thanks, > Richard > > > > -- > View this message in context: http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Jan. 13, 2017

Re: [Pharo-dev] Can anyone explain #asInteger for Strings?

by Guillermo Polito

Ugly. And old, really old. I remember at one point in time there was a "squeezeNumberOutOfString" or something like that. Now, I'd like to fix this, because it just introduces noise and probably a lot of strange code. But the problem is not fixing it on itself, but checking all possible users relying on such strange behaviour. I bet that fixing it naively could lead to break your image :). On Fri, Jan 13, 2017 at 4:05 AM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > I've come across an implementation of #asInteger and #asSignedInteger in > Pharo 3.0 that leaves me scratching my head. > > Can anyone explain why it was defined to answer what it does for strings > that one would really not expect to parse as a number. > > 'abc-123-xyz-897' asSignedInteger > ===> -123 > > To my mind, the method that does this for the example string should have an > intention revealing name like #spelunkIntegerFromString or some such. > > > Thanks, > Richard > > > > -- > View this message in context: http://forum.world.st/Can- > anyone-explain-asInteger-for-Strings-tp4929502.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Jan. 13, 2017

Re: [Pharo-dev] problem with linux: missing

by Norbert Hartl

The reason is that the vm binary is 64bit but the interpreter is for 32bit images. Therefor the plugins are 32bit, too. If there will be a 64bit vm plus image the dependencies would go away. We are close to that but not there. Norbert > Am 12.01.2017 um 15:00 schrieb Nicolas Anquetil <nicolas.anquetil(a)inria.fr>: > > thanks for both replies. > > - I was under the impression that the 64bit VM was precisely intended to remove dependencies on 32bits libraries ... ? > - and yes, you are right, I should have called on the plugin, not the vm > > thanks again > > nicolas > > > On 12/01/2017 14:43, Hilaire wrote: >> If you are using Pharo on a Linux 64 bits system you need the Linux 32 >> bits librararies. There are not installed by default on Linux. >> >> You can follow these procedure to install the missing 32 bits libraries: >> http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 <http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1> >> >> >> Le 12/01/2017 Ã 12:26, Nicolas Anquetil a Ã©crit : >>> a fresh install of moose image failed to start on a number of Linux >>> machines because of missing libraries >>> >>> the missing dependencies are libGL and libX11 that for some reasons were >>> not installed (but it was a running linux with graphical interface). >>> >>> See below >>> > On 12/01/2017 14:44, Nicolai Hess wrote: >> The vm-display-X11 >> will be dynamically loaded, that is why you don't see the GL/X11 dependency if you ldd on the vm (pharo-executable). >> >> If you are on a 64Bit machine, you need to have 32Bit libraries for X11/GL . And yes, it would be nice to have a headless vm not to depend on the display library stuff. >> >> 2017-01-12 14:38 GMT+01:00 Nicolas Anquetil <nicolas.anquetil(a)inria.fr <mailto:nicolas.anquetil@inria.fr>>: >> more info on this, >> >> On my own computer, the dependencies are not the same: >> >> --- >> >> $ ldd pharo >> linux-gate.so.1 => (0xf7751000) >> libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf76ce000) >> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76c9000) >> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76ab000) >> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74f5000) >> /lib/ld-linux.so.2 (0x565c6000) >> --- >> >> Specifically, the two missing libraries (for hte others) are not requested on my computer. >> So why were they needed in the other cases? (I am using the same pharo5 as they do) >> >> nicolas >> >> On 12/01/2017 12:26, Nicolas Anquetil wrote: >>> >>> a fresh install of moose image failed to start on a number of Linux machines because of missing libraries >>> >>> the missing dependencies are libGL and libX11 that for some reasons were not installed (but it was a running linux with graphical interface). >>> >>> See below >>> >>> --- >>> $ ldd vm-display-X11 >>> >>> linux-gate.so.1 => (0xf7766000) >>> libpthread.so.0 => /lib32/libpthread.so.0 (0xf76ff000) >>> libGL.so.1 => not found >>> libX11.so.6 => not found >>> libc.so.6 => /lib32/libc.so.6 (0xf754b000) >>> /lib/ld-linux.so.2 (0x5661f000) >>> >>> --- >>> >>> there should be a way to test that. >>> Not too sure how. May be an installer in the form of a headless image using the system ldd (see above) command ? >>> >>> >>> nicolas >>> >>> -- >>> Nicolas Anquetil -- MCF (HDR) >>> Project-Team RMod >> >> -- >> Nicolas Anquetil -- MCF (HDR) >> Project-Team RMod >> > > -- > Nicolas Anquetil -- MCF (HDR) > Project-Team RMod

Jan. 13, 2017

Can anyone explain #asInteger for Strings?

by Richard Sargent

I've come across an implementation of #asInteger and #asSignedInteger in Pharo 3.0 that leaves me scratching my head. Can anyone explain why it was defined to answer what it does for strings that one would really not expect to parse as a number. 'abc-123-xyz-897' asSignedInteger ===> -123 To my mind, the method that does this for the example string should have an intention revealing name like #spelunkIntegerFromString or some such. Thanks, Richard -- View this message in context: http://forum.world.st/Can-anyone-explain-asInteger-for-Strings-tp4929502.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 13, 2017

Re: [Pharo-dev] problem with linux: missing

by Dimitris Chloupis

The main purpose of the 64bit VM is to allow an image to have a size greater than 2GB There is nothing wrong with depending on 32bit libraries With a 32bit VM you still access mora than 2GB of memory using multiple images and vm instances and IPC On Thu, 12 Jan 2017 at 16:01, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > > > > > > > > > thanks for both replies. > > > - I was under the impression that the 64bit VM was precisely > > intended to remove dependencies on 32bits libraries ... ? > > > > > - and yes, you are right, I should have called on the plugin, not > > the vm > > > > > > thanks again > > > > > > > nicolas > > > > > > > > > > On 12/01/2017 14:43, Hilaire wrote: > > > > > > > If you are using Pharo on a Linux 64 bits system you need the Linux 32 > > bits librararies. There are not installed by default on Linux. > > > > You can follow these procedure to install the missing 32 bits libraries: > > http://www.drgeo.eu/faq#TOC-Debian-Jessie-Ubuntu-LinuxMint-12.04-LTS1 > > > > > > Le 12/01/2017 Ã 12:26, Nicolas Anquetil a Ã©crit : > > > > > > a fresh install of moose image failed to start on a number of Linux > > machines because of missing libraries > > > > the missing dependencies are libGL and libX11 that for some reasons were > > not installed (but it was a running linux with graphical interface). > > > > See below > > > > > > > > > > On 12/01/2017 14:44, Nicolai Hess > > wrote: > > > > > > > > > The vm-display-X11 > > > will be dynamically loaded, that is why you don't see the > > GL/X11 dependency if you ldd on the vm (pharo-executable). > > > > > > > > If you are on a 64Bit machine, you need to have 32Bit libraries > > for X11/GL . And yes, it would be nice to have a headless vm not > > to depend on the display library stuff. > > > > > > > > 2017-01-12 14:38 GMT+01:00 Nicolas > > Anquetil <nicolas.anquetil(a)inria.fr>: > > > > > > > more info on this, > > > On my own computer, the dependencies are not the same: > > > --- > > > $ ldd pharo > > > linux-gate.so.1 => (0xf7751000) > > > libm.so.6 => > > /lib/i386-linux-gnu/libm.so.6 (0xf76ce000) > > > libdl.so.2 => > > /lib/i386-linux-gnu/libdl.so.2 (0xf76c9000) > > > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 > > (0xf76ab000) > > > libc.so.6 => > > /lib/i386-linux-gnu/libc.so.6 (0xf74f5000) > > > /lib/ld-linux.so.2 (0x565c6000) > > > > > --- > > > Specifically, the two missing libraries (for hte > > others) are not requested on my computer. > > > > > So why were they needed in the other cases? (I am using > > the same pharo5 as they do) > > > > > > > nicolas > > > > > > > > > > > > > > > > On > > 12/01/2017 12:26, Nicolas Anquetil wrote: > > > > > > > > > > > > a fresh install of moose image failed to start on > > a number of Linux machines because of missing > > libraries > > > the missing dependencies are libGL and libX11 > > that for some reasons were not installed (but it > > was a running linux with graphical interface). > > > See below > > > --- > > > > > $ ldd vm-display-X11 > > > linux-gate.so.1 > > => (0xf7766000) > > > libpthread.so.0 > > => /lib32/libpthread.so.0 (0xf76ff000) > > > libGL.so.1 > > => not found > > > libX11.so.6 > > => not found > > > libc.so.6 > > => /lib32/libc.so.6 (0xf754b000) > > > /lib/ld-linux.so.2 > > (0x5661f000) > > > > > > --- > > > > > > there should be a way to test that. > > > Not too sure how. May be an installer in the form > > of a headless image using the system ldd (see > > above) command ? > > > > > > > > > nicolas > > > > > > > > -- > > Nicolas Anquetil -- MCF (HDR) > > Project-Team RMod > > > > > > > > > -- > > Nicolas Anquetil -- MCF (HDR) > > Project-Team RMod > > > > > > > > > > > > > > > > > > > > > > > > -- > > Nicolas Anquetil -- MCF (HDR) > > Project-Team RMod > > > >

Jan. 13, 2017

Re: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened

by John Brant

On 01/12/2017 08:03 AM, Henrik Nergaard wrote: > The test was meant to show the overhead when a symbol is used as a message argument instead of a block, not the evaluation of each of them by #value: > -------------------------------------------- > #(a b c) collect: #asUppercase "#('A' 'B' 'C')" > #(a b c) collect: [ :each | each asUppercase ]. "#('A' 'B' 'C')" > -------------------------------------------- Passing a symbol will be faster than creating and then passing a block. If the block has already been creating then both should be about the same speed. Evaluating a block is faster than evaluating a symbol like a block (i.e., sending the #value: message). Your initial tests used the #to:do: message. That message gets inlined when the last argument is a one argument block. The code for the first example "1 to: 1e9 do: [ :each | each ]" would have been inlined to look something like this: | current end | end := 1e9. current := 1. [current <= end] whileTrue: [current := current + 1] So there are no "real" block arguments as the "[:each | each]" gets removed. BTW, there is a bug in the #to:do: inlining. The first argument is evaluated before the receiver. Here's a test case that fails: | stream | stream := ReadStream on: #(2 1). stream next to: stream next do: [ :i | self error: 'This should not occur' ] This should be evaluated as "2 to: 1 do: ...". Instead it is evaluated as "1 to: 2 do: ..." . John Brant

Jan. 12, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Hilaire

Le 12/01/2017 Ã 15:29, Denis Kudriashov a Ã©crit : > You need latest version of Pharo 6. New method is there. Ok > But how you suggest to distinguish user intention? what to use as query > source: method from method view or current message in code editor? Easy: if no text selected in code editor -> query from method view, otherwise -> query from selected method in code editor. Tools tips of the implementors and senders buttons should document it to make the feature discoverable by user. > And of course it should open in new tab too. > > > Yes. Problem that I not hook into text editor yet. So any navigation > from source code is standard Pharo "global commands". But I need to use > Calypso commands instead. And it is not trivial task to hack this place. I guess so, but you will be real winner. -- Dr. Geo http://drgeo.eu

Jan. 12, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Denis Kudriashov

2017-01-12 15:08 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > The tabs on the MessageBrowser really reduces the window noise. > I see these error when asking for implementors: > "Instance of AColorSelectorMorph class did not understand > #localMethodNamed:ifAbsent:" > You need latest version of Pharo 6. New method is there. > > > Something really cool, will be the implementors and sender button to > work too for selected method in the source code area. > I know we can get it from the contextual menu 'Code search...', but it > is so common to search for implementor and senders of methods used in > the source code itself. > But how you suggest to distinguish user intention? what to use as query source: method from method view or current message in code editor? > And of course it should open in new tab too. > Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place.

Jan. 12, 2017

Re: [Pharo-dev] problem with linux: missing

by Hilaire

I don't knwo. Did you installed the 64bits VM and Pharo 64 bits image. I think it is still WIP. Le 12/01/2017 Ã 15:00, Nicolas Anquetil a Ã©crit : > - I was under the impression that the 64bit VM was precisely intended to > remove dependencies on 32bits libraries ... ? -- Dr. Geo http://drgeo.eu

Jan. 12, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Hilaire

It looks great! The tabs on the MessageBrowser really reduces the window noise. I see these error when asking for implementors: "Instance of AColorSelectorMorph class did not understand #localMethodNamed:ifAbsent:" Something really cool, will be the implementors and sender button to work too for selected method in the source code area. I know we can get it from the contextual menu 'Code search...', but it is so common to search for implementor and senders of methods used in the source code itself. And of course it should open in new tab too. Hilaire Le 12/01/2017 Ã 12:07, Denis Kudriashov a Ã©crit : > Hi. > > I glad release new version of Calypso: -- Dr. Geo http://drgeo.eu

Jan. 12, 2017