- Pharo-dev - lists.pharo.org

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

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

by Henrik Nergaard

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')" -------------------------------------------- Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av John Brant Sendt: 12 January 2017 14:40 Til: pharo-dev(a)lists.pharo.org Emne: Re: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened On 01/12/2017 06:45 AM, Julien Delplanque wrote: > On 12/01/17 12:32, Henrik Nergaard wrote: >> Ps. Using a symbol instead of a block reduces performance. >> [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463" >> [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468" > Wow, I used symbols to make the example clear but I didn't know that. > That's sad, I think it is sexier to use a symbol to do this kind of > things. :( I'm not sure what this test is supposed to show. The first one is just a loop counting to 1 billion inlined in a method. The second one is a message send of #to:do: which is implemented as a whileTrue: loop which will send the #value: message to #yourself. Essentially, it is showing the time to evaluate "#yourself value: someInt" 1 billion times. I think that a better test to show the performance difference is this: [ 1 to: 1000000000 do: [ :i | [ :e | e ] value: i ] ] timeToRun. "0:00:00:14.917" [ 1 to: 1000000000 do: [ :i | #yourself value: i ] ] timeToRun. "0:00:00:07.846" These results might lead you to believe that symbols are faster than blocks. However, the first one is also creating 1 billion blocks. If we create the block once, then blocks are faster: [ | b | b := [ :e | e ]. 1 to: 1000000000 do: [ :i | b value: i ] ] timeToRun. "0:00:00:04.515" So, if you know how many blocks you will create and how often each block is evaluated, you could come up with the optimal solution. Or, you could just write your code so the intent is expressed clearly and not worry about performance until it is needed. John Brant

Jan. 12, 2017

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

by Nicolas Anquetil

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 > <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. 12, 2017

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

by Nicolai Hess

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 > >

Jan. 12, 2017

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

by Hilaire

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 > -- Dr. Geo http://drgeo.eu

Jan. 12, 2017

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

by John Brant

On 01/12/2017 06:45 AM, Julien Delplanque wrote: > On 12/01/17 12:32, Henrik Nergaard wrote: >> Ps. Using a symbol instead of a block reduces performance. >> [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463" >> [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468" > Wow, I used symbols to make the example clear but I didn't know that. > That's sad, I think it is sexier to use a symbol to do this kind of > things. :( I'm not sure what this test is supposed to show. The first one is just a loop counting to 1 billion inlined in a method. The second one is a message send of #to:do: which is implemented as a whileTrue: loop which will send the #value: message to #yourself. Essentially, it is showing the time to evaluate "#yourself value: someInt" 1 billion times. I think that a better test to show the performance difference is this: [ 1 to: 1000000000 do: [ :i | [ :e | e ] value: i ] ] timeToRun. "0:00:00:14.917" [ 1 to: 1000000000 do: [ :i | #yourself value: i ] ] timeToRun. "0:00:00:07.846" These results might lead you to believe that symbols are faster than blocks. However, the first one is also creating 1 billion blocks. If we create the block once, then blocks are faster: [ | b | b := [ :e | e ]. 1 to: 1000000000 do: [ :i | b value: i ] ] timeToRun. "0:00:00:04.515" So, if you know how many blocks you will create and how often each block is evaluated, you could come up with the optimal solution. Or, you could just write your code so the intent is expressed clearly and not worry about performance until it is needed. John Brant

Jan. 12, 2017

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

by Nicolas Anquetil

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

Jan. 12, 2017

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

by Julien Delplanque

On 12/01/17 12:32, Henrik Nergaard wrote: >> Shouldn't these two code snippets behave the same way? > #flatCollect: expects that aBlock returns a collection for each element (see method comment) and only flattens one level, while # flattened expands all sub collections it finds: > ---------------------------------------------------------------- > #( #(1 #(2) ) ) flatCollect: [ :x | x ]. "#(1 #(2))" > #( #(1 #(2) ) ) flattened. "#(1 2)" > ---------------------------------------------------------------- Oh, ok so it's a feature :) > > Ps. Using a symbol instead of a block reduces performance. > [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463" > [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468" Wow, I used symbols to make the example clear but I didn't know that. That's sad, I think it is sexier to use a symbol to do this kind of things. :( Regards, Julien

Jan. 12, 2017

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

by Henrik Nergaard

>Shouldn't these two code snippets behave the same way? #flatCollect: expects that aBlock returns a collection for each element (see method comment) and only flattens one level, while # flattened expands all sub collections it finds: ---------------------------------------------------------------- #( #(1 #(2) ) ) flatCollect: [ :x | x ]. "#(1 #(2))" #( #(1 #(2) ) ) flattened. "#(1 2)" ---------------------------------------------------------------- Ps. Using a symbol instead of a block reduces performance. [ 1 to: 1e9 do: [ :each | each ] ] timeToRun. "0:00:00:02.463" [ 1 to: 1e9 do: #yourself ] timeToRun. "0:00:00:11.468" Best regards, Henrik -----Opprinnelig melding----- Fra: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] PÃ¥ vegne av Julien Delplanque Sendt: 12 January 2017 11:27 Til: Pharo Development List <pharo-dev(a)lists.pharo.org> Emne: [Pharo-dev] collection flatCollect: #something VS (collection collect: #something) flattened Hello everyone, While using #flatCollect: on a collection, I realized that, for example, these two code snippets do not behave the same way: #(1 (1)) flatCollect: #yourself. "Raise an error because the array does not contain only collections" (#(1 (1)) collect: #yourself) flattened "Returns #(1 1) Shouldn't these two code snippets behave the same way? Thanks in advance for your answers. Regards, Julien

Jan. 12, 2017

problem with linux: missing

by Nicolas Anquetil

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

Jan. 12, 2017