- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about propertyAt: and others

by phil＠highoctane.be

What is Cocoon? Phil <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Sat, Mar 18, 2017 at 1:18 PM, stepharong <stepharong(a)free.fr> wrote: > Hi > > I'm looking at cocoon and other property systems. I would like to get a > nice library once for all. > I want to also revisit Artefact stylesheets. > > I'm checking the semantics regarding the lookup of a property in a parent > when it is not found in the receiver. > > I have the impression that when there is a parent access and modification > should modify the same object: i.e., the parent if the key is found in the > parent or the child if the property is found in the child. > > > in cocoon we have a mix of the two semantics and I would like to get your > feel about it. > > propertyAt: aKey > "Answer the value of the property ==aKey==, raises an error if the > property doesn't exist." > > ^ self propertyAt: aKey ifAbsent: [ > self hasParent > ifTrue: [ self parent propertyAt: aKey ] > ifFalse: [self errorPropertyNotFound: aKey ]] > > propertyAt: aKey default: aBlock > "Answer the value of ==aKey==. If the key have no entry I look on > the parent or execute a block if i'm an orphan." > > ^ self > propertyAt: aKey > ifAbsent: [ > self hasParent > ifTrue: [ self parent propertyAt: aKey > default: aBlock ] > ifFalse: aBlock ] > > but > > propertyAt: aKey ifAbsent: aBlock > "Answer the value of the property ==aKey==, or the result of > ==aBlock== if the property doesn't exist." > > ^ self properties at: aKey ifAbsent: aBlock > > propertyAt: aKey ifAbsentPut: aBlock > "Answer the value of the property ==aKey==, or if the property > doesn't exist adds and answers the result of evaluating ==aBlock==." > > ^ self properties at: aKey ifAbsentPut: aBlock > > > > In PetitParser there is no lookup. But we can get back to this situation > by just not setting a parent. > My gut feeling is telling me that overriding on write is not really good > because > a client of the parent will not see the changes coming from a child. > > > I thaought that stylesheet was supporting lookup but it does not > > testSubstyleAttributesOverride > styleSheet at: #textColor put: #red. > styleSheet > #sub > #subsub at: #textColor put: #blue. > self assert:( styleSheet get: #textColor ) equals: #red. > self assert:( styleSheet > #sub get: #textColor ) equals: #red. > self assert:( styleSheet > #sub > #subsub get: #textColor ) > equals: #blue. > Does not work > > > What you think? > > Stef > >

March 18, 2017

platforms/Nopsys submodule

by Ben Coman

In the network graph hovering over charig/2-March commit I see a new platform Nopsys added for SqueakNOS. [A] https://github.com/OpenSmalltalk/opensmalltalk-vm/network Thats cool !!! It'll be great to see this work with OpenSmalltalk. However I notice its been added as a submodule. [B] https://github.com/charig/opensmalltalk-vm/commit/2bd87b525b6b46439c90506c0… Submodules bring additional complexity, so I thought there should be some discussion on this topic. Here are a couple of balanced introductions to submodules... [C] http://www.catalyst-au.net/blog/git-submodule-misunderstood-beast-or-remors… [D] https://www.philosophicalhacker.com/post/using-git-submodules-effectively/ And a couple of cautions about using them... [E] http://slopjong.de/2013/06/04/git-why-submodules-are-evil/ [F] https://rufflewind.com/2017-02-21/quirks-with-submodules Guido & Javier, Have you used submodules successfully elsewhere? Could you discuss your strategy using a submodule for the platform code rather than adding directly into the opensmalltalk-vm repository? I see your parent repository includes opensmalltalk-vm as a submodule similar to how I *thought* Pharo was doing it, but wait on comment from Esteban. . [G] https://github.com/charig/Nopsys [H] https://github.com/charig/Nopsys/blob/master/.gitmodules So it seems platforms/Nopsys is a sub-sub-module. Esteban, I thought that you were using submodules to incorporate opensmalltlak-vm into the pharo-vm, but I can't see a .gitmodules file there. [I] https://github.com/pharo-project/pharo-vm So did you do it another way, or am I missing something? Could you report your experience with adding opensmalltalk-vm into the pharo-vm repository? cheers -ben

March 18, 2017

about propertyAt: and others

by stepharong

Hi I'm looking at cocoon and other property systems. I would like to get a nice library once for all. I want to also revisit Artefact stylesheets. I'm checking the semantics regarding the lookup of a property in a parent when it is not found in the receiver. I have the impression that when there is a parent access and modification should modify the same object: i.e., the parent if the key is found in the parent or the child if the property is found in the child. in cocoon we have a mix of the two semantics and I would like to get your feel about it. propertyAt: aKey "Answer the value of the property ==aKey==, raises an error if the property doesn't exist." ^ self propertyAt: aKey ifAbsent: [ self hasParent ifTrue: [ self parent propertyAt: aKey ] ifFalse: [self errorPropertyNotFound: aKey ]] propertyAt: aKey default: aBlock "Answer the value of ==aKey==. If the key have no entry I look on the parent or execute a block if i'm an orphan." ^ self propertyAt: aKey ifAbsent: [ self hasParent ifTrue: [ self parent propertyAt: aKey default: aBlock ] ifFalse: aBlock ] but propertyAt: aKey ifAbsent: aBlock "Answer the value of the property ==aKey==, or the result of ==aBlock== if the property doesn't exist." ^ self properties at: aKey ifAbsent: aBlock propertyAt: aKey ifAbsentPut: aBlock "Answer the value of the property ==aKey==, or if the property doesn't exist adds and answers the result of evaluating ==aBlock==." ^ self properties at: aKey ifAbsentPut: aBlock In PetitParser there is no lookup. But we can get back to this situation by just not setting a parent. My gut feeling is telling me that overriding on write is not really good because a client of the parent will not see the changes coming from a child. I thaought that stylesheet was supporting lookup but it does not testSubstyleAttributesOverride styleSheet at: #textColor put: #red. styleSheet > #sub > #subsub at: #textColor put: #blue. self assert:( styleSheet get: #textColor ) equals: #red. self assert:( styleSheet > #sub get: #textColor ) equals: #red. self assert:( styleSheet > #sub > #subsub get: #textColor ) equals: #blue. Does not work What you think? Stef

March 18, 2017

Re: [Pharo-dev] Script to download Pharo 4 vm for Mac os sierra

by Cyril Ferlicot D.

Le 18/03/2017 Ã 11:47, Esteban Lorenzano a Ã©crit : > because that link is incorrect, and you should not use it (it was a > development stage that once released 4.0 was never updated again). > you (and everybody else) needs to use the stable VM for pharo 4.0: > If it is never updated again maybe it should be removed? > http://files.pharo.org/get-files/40/pharo-mac-stable.zip (which is the > one that zeroconf uses) > http://files.pharo.org/platform/Pharo4.0-mac.zip for the âall inclusiveâ > (with image) download. > > >> >> Is there a script that allows to download a pharo 4 vm working for >> mac os sierra, from a linux machine ? > > this phrase does not has sense :) > you can use a macOS VM just in macOS, and a linux VM in linux. > This sentence make sense in our context :) Our Jenkins only got Linux's slaves and we want to produce some zip to deploy a server on mac (vm included). If we use zeroconf we can only get the Linux vm (or there is an option I missed). > Anyway for linux links are: > > http://files.pharo.org/get-files/40/pharo-linux-stable.zip > http://files.pharo.org/platform/Pharo4.0-linux.zip > > cheers, > Esteban > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

March 18, 2017

Re: [Pharo-dev] Script to download Pharo 4 vm for Mac os sierra

by Esteban Lorenzano

> On 17 Mar 2017, at 21:56, stepharong <stepharong(a)free.fr> wrote: > > Nice to see on this list after all these years :) > This is important for synectiquers to use the power of the open-source :) > > > > Hello, > > We have a jenkins job, running on a linux machine, that is responsible for building and outputing a Pharo 4 development image + vm ready to be used on mac machines. > > We use this command line to download the VM and archived it as output of the job: > > curl -O http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip <http://files.pharo.org/vm/pharo/mac/Pharo-VM-mac-latest.zip> > > On my mac (10.12.1), when i open the pharo image with this vm , I am facing what seem to be some known issues for Mac OS sierra: > > Pharo[13048:431565] *** -[NSPathStore2 stringByAppendingPathExtension:]: cannot append extension 'bundle/Contents/MacOS/' to path ... > > Now, when I try to download a Pharo 4 vm directly from my mac sierra machine, > with a zeroconf script (get.pharo.org/vm40 <http://get.pharo.org/vm40>), > It works: I am able to open the pharo image with this vm. because that link is incorrect, and you should not use it (it was a development stage that once released 4.0 was never updated again). you (and everybody else) needs to use the stable VM for pharo 4.0: http://files.pharo.org/get-files/40/pharo-mac-stable.zip <http://files.pharo.org/get-files/40/pharo-mac-stable.zip> (which is the one that zeroconf uses) http://files.pharo.org/platform/Pharo4.0-mac.zip <http://files.pharo.org/platform/Pharo4.0-mac.zip> for the âall inclusiveâ (with image) download. > > Is there a script that allows to download a pharo 4 vm working for mac os sierra, from a linux machine ? this phrase does not has sense :) you can use a macOS VM just in macOS, and a linux VM in linux. Anyway for linux links are: http://files.pharo.org/get-files/40/pharo-linux-stable.zip <http://files.pharo.org/get-files/40/pharo-linux-stable.zip> http://files.pharo.org/platform/Pharo4.0-linux.zip <http://files.pharo.org/platform/Pharo4.0-linux.zip> cheers, Esteban > > -- > Cyrille Delaunay > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/>

March 18, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-03-17 23:41 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-03-17 23:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> >>>> >>>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>> >>>>>> sorry for coming late to this threadâ¦ hard week :) >>>>>> why we are trying to compile with cygwin? >>>>>> is there a problem with the mingw distro? >>>>>> >>>>>> I didnât have the time to update the README, sadly. But wellâ¦ >>>>>> following appveyor configuration should give you all you need to reproduce >>>>>> the build (thatâs what I did last time I built an environment). >>>>>> >>>>>> Esteban >>>>>> >>>>>> >>>>>> Hi Esteban, >>>>> How did you solve the directx problem? >>>>> >>>>> >>>> >>>> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using >>>> cross-compiler i686-w64-mingw32 >>>> (cygwin64 here but it could be cygwin32). >>>> >>>> This is good news, because it means that: >>>> - we don't have to rely anymore on non-redistributable legacy directx >>>> SDK >>>> - we can compile with clang if we want too (well, for all the 3rd party >>>> dependencies, that's a bit more work) >>>> - it opens the door to win64 version >>>> >>>> Some details remain: I have to pick the right libgcc and libwindpthread >>>> as weel as iconv.dll and copy them to the pharo build directory to satisfy >>>> the SDL2 dependencies. >>>> Maybe there's a better option for compiling SDL2 with more static >>>> stuff? -static-libgcc or something... >>>> >>>> cairo required another dirty hack, not the one of Igor which must be >>>> eliminated for cygwin compilation, but one for working around the files >>>> that are not truncated when overwritten... >>>> I wonder where this bug comes from? make? cygwin itself? VirtualBox >>>> (unlikely)? >>>> >>> >>> what hack from Igor ? I thought the pharo build just downloads a tar.gz >>> archive from cairo and starts the configure/build ? >>> >>> >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d >> 3c98eaa001d2d07c1f2b75cad00fa16f86a73 >> >> > and https://lists.cairographics.org/archives/cairo/2012- > October/023675.html > Ok :)

March 17, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

2017-03-17 23:40 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-03-16 21:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> >>> >>> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> >>>> >>>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>>> sorry for coming late to this threadâ¦ hard week :) >>>>> why we are trying to compile with cygwin? >>>>> is there a problem with the mingw distro? >>>>> >>>>> I didnât have the time to update the README, sadly. But wellâ¦ >>>>> following appveyor configuration should give you all you need to reproduce >>>>> the build (thatâs what I did last time I built an environment). >>>>> >>>>> Esteban >>>>> >>>>> >>>>> Hi Esteban, >>>> How did you solve the directx problem? >>>> >>>> >>> >>> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using >>> cross-compiler i686-w64-mingw32 >>> (cygwin64 here but it could be cygwin32). >>> >>> This is good news, because it means that: >>> - we don't have to rely anymore on non-redistributable legacy directx SDK >>> - we can compile with clang if we want too (well, for all the 3rd party >>> dependencies, that's a bit more work) >>> - it opens the door to win64 version >>> >>> Some details remain: I have to pick the right libgcc and libwindpthread >>> as weel as iconv.dll and copy them to the pharo build directory to satisfy >>> the SDL2 dependencies. >>> Maybe there's a better option for compiling SDL2 with more static stuff? >>> -static-libgcc or something... >>> >>> cairo required another dirty hack, not the one of Igor which must be >>> eliminated for cygwin compilation, but one for working around the files >>> that are not truncated when overwritten... >>> I wonder where this bug comes from? make? cygwin itself? VirtualBox >>> (unlikely)? >>> >> >> what hack from Igor ? I thought the pharo build just downloads a tar.gz >> archive from cairo and starts the configure/build ? >> >> > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ > f7d3c98eaa001d2d07c1f2b75cad00fa16f86a73 > > and https://lists.cairographics.org/archives/cairo/2012-October/023675.html

March 17, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

2017-03-17 23:32 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-03-16 21:51 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> >>> >>> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>>> sorry for coming late to this threadâ¦ hard week :) >>>> why we are trying to compile with cygwin? >>>> is there a problem with the mingw distro? >>>> >>>> I didnât have the time to update the README, sadly. But wellâ¦ following >>>> appveyor configuration should give you all you need to reproduce the build >>>> (thatâs what I did last time I built an environment). >>>> >>>> Esteban >>>> >>>> >>>> Hi Esteban, >>> How did you solve the directx problem? >>> >>> >> >> Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using >> cross-compiler i686-w64-mingw32 >> (cygwin64 here but it could be cygwin32). >> >> This is good news, because it means that: >> - we don't have to rely anymore on non-redistributable legacy directx SDK >> - we can compile with clang if we want too (well, for all the 3rd party >> dependencies, that's a bit more work) >> - it opens the door to win64 version >> >> Some details remain: I have to pick the right libgcc and libwindpthread >> as weel as iconv.dll and copy them to the pharo build directory to satisfy >> the SDL2 dependencies. >> Maybe there's a better option for compiling SDL2 with more static stuff? >> -static-libgcc or something... >> >> cairo required another dirty hack, not the one of Igor which must be >> eliminated for cygwin compilation, but one for working around the files >> that are not truncated when overwritten... >> I wonder where this bug comes from? make? cygwin itself? VirtualBox >> (unlikely)? >> > > what hack from Igor ? I thought the pharo build just downloads a tar.gz > archive from cairo and starts the configure/build ? > > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/f7d3c98eaa001d2d07…

March 17, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-03-16 21:51 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-03-15 18:14 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-03-15 15:03 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> sorry for coming late to this threadâ¦ hard week :) >>> why we are trying to compile with cygwin? >>> is there a problem with the mingw distro? >>> >>> I didnât have the time to update the README, sadly. But wellâ¦ following >>> appveyor configuration should give you all you need to reproduce the build >>> (thatâs what I did last time I built an environment). >>> >>> Esteban >>> >>> >>> Hi Esteban, >> How did you solve the directx problem? >> >> > > Hurrah, I succeeded in compiling Win32 Pharo VM from cygwin by using > cross-compiler i686-w64-mingw32 > (cygwin64 here but it could be cygwin32). > > This is good news, because it means that: > - we don't have to rely anymore on non-redistributable legacy directx SDK > - we can compile with clang if we want too (well, for all the 3rd party > dependencies, that's a bit more work) > - it opens the door to win64 version > > Some details remain: I have to pick the right libgcc and libwindpthread as > weel as iconv.dll and copy them to the pharo build directory to satisfy the > SDL2 dependencies. > Maybe there's a better option for compiling SDL2 with more static stuff? > -static-libgcc or something... > > cairo required another dirty hack, not the one of Igor which must be > eliminated for cygwin compilation, but one for working around the files > that are not truncated when overwritten... > I wonder where this bug comes from? make? cygwin itself? VirtualBox > (unlikely)? > what hack from Igor ? I thought the pharo build just downloads a tar.gz archive from cairo and starts the configure/build ? > > If I find the energy to rebase -i and clean a bit my non linear attempts > (squash/reorder/...) then I'll push the branch on opensmalltalk-vm and see > how appveyor like it. > > > > >> On 15 Mar 2017, at 10:11, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2017-03-15 9:22 GMT+01:00 philippe.back(a)highoctane.be < >>> philippe.back(a)gmail.com>: >>> >>>> I made my own build here. >>>> Not up to date with latest stuff but should work for the build process. >>>> >>>> https://ci.appveyor.com/project/philippeback/pharo-vm >>>> >>>> It uses my forked repo and provided you set your own bintray env vars >>>> for API keys will publish there. >>>> >>>> Check all of the output of env vars and where/which in the appveyor >>>> console to see what gets used when when it comes to compilers and so on as >>>> there were various compiler versions involved at one point. >>>> >>>> Third party cache part is also worth checking. >>>> >>>> Still not able to build on my local box at the moment due to some tools >>>> discrepancies happening. >>>> >>>> My build artifacts are embarking too much at this point but allow you >>>> ro get the release, debug, and assert vms for windows. This helps when >>>> debugging as backtraces and so on are much more meaningful and one can use >>>> gdb more effectively to understand what is going on. >>>> >>>> Just keep the dlls and exes and you'll be fine. >>>> >>> >>> Ah good, thank you. >>> >>> >>> >>>> >>>> HTH >>>> >>>> Phil >>>> >>>> Le 15 mars 2017 08:58, "Nicolai Hess" <nicolaihess(a)gmail.com> a Ã©crit : >>>> >>>>> >>>>> >>>>> 2017-03-14 22:22 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>> ice(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-03-14 9:30 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>>> ice(a)gmail.com>: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-03-14 8:58 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2017-03-11 10:01 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.n >>>>>>>> ice(a)gmail.com>: >>>>>>>> >>>>>>>>> Hi Nicolai, >>>>>>>>> >>>>>>>>> If you look at appveyor.yml configuration on >>>>>>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Co >>>>>>>>> g/.appveyor.yml, you will see that the pharo brand is not yet in >>>>>>>>> the matrix. >>>>>>>>> >>>>>>>>> It's because builds are based on cygwin, but as I understood, some >>>>>>>>> library used by some plugin required by pharo refuse to compile with >>>>>>>>> cygwin. They appear to work with mingw32. >>>>>>>>> Cygwin provides headers for legacy directx, some distribution of >>>>>>>>> mingw32 did in the past, but it does not seem the case anymore. >>>>>>>>> Using the directx headers from Microsoft SDK is a problem. They >>>>>>>>> are not redistributable and can't be found anymore on the net (too old). We >>>>>>>>> cannot seriously base the builds on something so fragile (both technically >>>>>>>>> and legally) in the long term. >>>>>>>>> >>>>>>>>> Also, the 64 bits VM does only work with clang, and we don't have >>>>>>>>> anything available as a 64bits Microsoft SDK... So pharo has to fix that >>>>>>>>> too. >>>>>>>>> >>>>>>>>> In the interim, you should look at https://github.com/pharo-pr >>>>>>>>> oject/pharo-vm/blob/master/.appveyor.yml and follow the scripts >>>>>>>>> there. >>>>>>>>> >>>>>>>> >>>>>>>> Ok, thank you. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I gave it a shot on sunday, because it was particularly rainy in >>>>>>> Nantes, and I almost succeeded in compiling all the dependencies with >>>>>>> cygwin. >>>>>>> Well, I mean with autotools cmake libtool pkg-config and I surely >>>>>>> forget a few other niceties that some not so well informed programmers >>>>>>> committed with the faith that it would make their life "easier". It >>>>>>> certainly does not make mine simpler... >>>>>>> Almost, because gcc 5.4.0 failed to compile cairo with ssize_t: it >>>>>>> seems that the workaround of Igor does not work anymore. >>>>>>> ssize_t, WTF??? >>>>>>> Maybe I'll be able to fix it tonight. Or tomorrow. In which case >>>>>>> I'll publish the branch to see how far appveyor goes. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> So I solved the ssize_t problem by removing the hack from Igor which >>>>>> is not necessary anymore... >>>>>> But got another problem soon after while building the tests... >>>>>> There are trailing lines generated at end of >>>>>> tests/cairo-test-constructors.c that make the compilation fail: >>>>>> >>>>>> i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I./pdiff >>>>>> -I../boilerplate -I../util/cairo-missing -I../util/cairo-script -I../src >>>>>> -I../src -D_REENTRANT -I/cygdrive/y/Smalltalk/opensm >>>>>> alltalk-vm/.thirdparty-cache/windows/i386/include/pixman-1 >>>>>> -I/cygdrive/y/Smalltalk/opensmalltalk-vm/.thirdparty-cach >>>>>> e/windows/i386/include/libpng16 -Wall -Wextra >>>>>> -Wmissing-declarations -Werror-implicit-function-declaration >>>>>> -Wpointer-arith -Wwrite-strings -Wsign-compare -Wpacked -Wswitch-enum >>>>>> -Wmissing-format-attribute -Wvolatile-register-var -Wstrict-aliasing=2 >>>>>> -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers >>>>>> -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline >>>>>> -fno-strict-aliasing -fno-common -Wp,-D_FORTIFY_SOURCE=2 >>>>>> -Wno-unused-but-set-variable -D_REENTRANT -m32 >>>>>> -static-libgcc -static-libstdc++ -I/cygdrive/y/Smalltalk/opensm >>>>>> alltalk-vm/.thirdparty-cache/windows/i386/include -march=pentium4 -c >>>>>> -o cairo_test_suite-cairo-test-constructors.o `test -f >>>>>> 'cairo-test-constructors.c' || echo './'`cairo-test-constructors.c >>>>>> cairo-test-constructors.c:1118:1: attention : la dÃ©finition de >>>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>>> oning (); >>>>>> ^ >>>>>> cairo-test-constructors.c:1118:1: attention : type defaults to âintâ >>>>>> in declaration of âoningâ [-Wimplicit-int] >>>>>> cairo-test-constructors.c:1119:5: attention : la dÃ©finition de >>>>>> donnÃ©es n'a pas de type ni de classe de stockage >>>>>> _register_ft_show_glyphs_table (); >>>>>> ^ >>>>>> >>>>>> And the file looks like it has obviously been overwritten, but not >>>>>> truncated !!! >>>>>> >>>>>> ... >>>>>> extern void _register_multi_page (void); >>>>>> extern void _register_fallback_resolution (void); >>>>>> >>>>>> void >>>>>> _cairo_test_runner_register_tests (void) >>>>>> { >>>>>> _register_a1_bug (); >>>>>> _register_a1_clip_paint (); >>>>>> ... >>>>>> _register_multi_page (); >>>>>> _register_fallback_resolution (); >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *oning (); _register_ft_show_glyphs_table >>>>>> (); _register_ft_text_vertical_layout_type1 >>>>>> (); _register_ft_text_vertical_layout_type3 >>>>>> (); _register_ft_text_antialias_none (); _register_ps_eps >>>>>> (); _register_ps_features (); _register_ps_surface_source >>>>>> (); _register_svg_surface (); _register_svg_clip >>>>>> (); _register_svg_surface_source (); _register_multi_page >>>>>> (); _register_fallback_resolution ();}* >>>>>> >>>>>> This file is generated by a shell script >>>>>> test/make-cairo-test-constructors.sh >>>>>> I can't find any reference of the bug, and upgrade to version 1.14.8 >>>>>> does not solve the issue. >>>>>> So it will wait until tomorrow... >>>>>> >>>>> >>>>> >>>>> I got the build for windows with mingw nearly working. (it can not >>>>> build some plugins, like SqueakSSL for windows, because the used wincrypt.h >>>>> is different in the mingw distrubtion). >>>>> >>>>> I still have the problem, that there seems to be a preprocessing step >>>>> , that should put the vm-version (and source timestamp) in the >>>>> *sqSCCSVersion.h* >>>>> I got this working by running .travis_build.sh (with the options for >>>>> arch/flavor/platform) But how is this done normally when you build a vm >>>>> locally? >>>>> And how is this done for the pharo-vm we currently use? >>>>> >>>>> >>>>> >>>>>> >>>>>> Nicolas >>>>>> >>>>>> >>>>>>>>> I hope that Esteban will find time to resolve all these problems >>>>>>>>> and have pharo brand back on opensmalltalk-vm. I guess that any form of >>>>>>>>> help is welcome. >>>>>>>>> >>>>>>>>> Nicolas >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-03-11 8:33 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>> >>>>>>>>>> I still have problems building a vm on windows. >>>>>>>>>> can you give me some hints how to start ? >>>>>>>>>> I cloned the recent pharo-vm project, >>>>>>>>>> in opensmalltalk-vm\build.win32x86\pharo.cog.spur\ >>>>>>>>>> run >>>>>>>>>> mvm >>>>>>>>>> >>>>>>>>>> But I got a couple of problems (mingw-32 compiler commands not >>>>>>>>>> found, I had to adjust the include path for finding directx header, missing >>>>>>>>>> variable replacement for git-versions). >>>>>>>>>> So I may miss some important steps. >>>>>>>>>> Is there a repository where I can clone the mingw environment >>>>>>>>>> used to build the win32-pharo-vm, the environment used on the build-server ? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Nicolai >>>>>>>>>> >>>>>>>>>> 2017-02-04 1:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-02-04 1:44 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-01-23 8:59 GMT+01:00 Esteban Lorenzano < >>>>>>>>>>>> estebanlm(a)gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 22 Jan 2017, at 13:19, Nicolai Hess <nicolaihess(a)gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-01-22 10:21 GMT+01:00 ClÃ©ment Bera < >>>>>>>>>>>>> bera.clement(a)gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I believe they're built from* https://github.com/OpenSmalltalk/vm >>>>>>>>>>>>>> <https://github.com/OpenSmalltalk/vm>* using travis and >>>>>>>>>>>>>> appveyor. On the gitbhub readme there are relevant links. All built >>>>>>>>>>>>>> artifacts are also kept on bintray for history. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Thank you! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> no, they arenât :) >>>>>>>>>>>>> instead, they are built here: https://github.com/pharo >>>>>>>>>>>>> -project/pharo-vm >>>>>>>>>>>>> >>>>>>>>>>>>> (README still not updated) >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> what did changed ? I am not able to build the vm on windows >>>>>>>>>>>> anymore (something wrong with generating the generator.image, I'll now >>>>>>>>>>>> reset my local pharo-vm build directory and see if it works afterwards). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> see attached the stderr log : >>>>>>>>>>> >>>>>>>>>>> 'Errors in script loaded from u:\github\pharo-vm\scripts\Loa >>>>>>>>>>> dVMMaker.st' >>>>>>>>>>> [31mMessageNotUnderstood: receiver of "default:" is nil >>>>>>>>>>> [0mUndefinedObject(Object)>>doesNotUnderstand: #default: >>>>>>>>>>> BaseSoundSystem class>>initialize >>>>>>>>>>> MCMethodDefinition>>postloadOver: >>>>>>>>>>> >>>>>>>>>>> .... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Are we still working with branch spur-64, or are we back on >>>>>>>>>>>> master ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Esteban >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Jan 22, 2017 at 9:25 AM, Nicolai Hess < >>>>>>>>>>>>>> nicolaihess(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Where are the latest Pharo-spur-vms (32bit) are built? >>>>>>>>>>>>>>> I don't see them on the build server, only the buildresults >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>> http://files.pharo.org/vm/pharo-spur32/linux/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The latest builds on the buildserver are from the last year >>>>>>>>>>>>>>> only. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> nicolai >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >> >

March 17, 2017

Re: [Pharo-dev] Pharo7 Inspector feature idea - cherry-pick collection items

by Alistair Grant

On 17 March 2017 at 12:40, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Mar 17, 2017 at 5:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> That list is multi-selection. On Mac, you can press Cmd while clicking and >> you get the collection to the right. >> >> > > I now see that Shift-click multi-selects and works just like I imagined it > would. > However Ctrl-click doesn't do anything, which was the only thing I tested > before. > I presume that is a bug? Can anyone confirm this on Linux? > > I'm... 32-bit Debian 8 Jessie. > Pharo 60447 & Unix VM built on Mar 3 2017 21:07:26 Compiler: 4.6.3 > VMMaker versionString VM: 201703031554 > https://github.com/pharo-project/pharo-vm.git $ Date: Fri Mar 3 16:54:16 > 2017 +0100 $ Plugins: 201703031554 > https://github.com/pharo-project/pharo-vm.git $ > CoInterpreter * VMMaker.oscog-eem.2143 uuid: > fe064b6b-e530-4766-837d-799ffe1e8dcd Mar 3 2017 > StackToRegisterMappingCogit * VMMaker.oscog-eem.2143 uuid: > fe064b6b-e530-4766-837d-799ffe1e8dcd Mar 3 2017 I have the same behaviour (can't multi-select using Ctrl-click on linux): Ubuntu 16.04 Pharo 6.0 Latest update: #60438 5.0-201702221539 Wed Feb 22 15:46:29 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017 VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Linux testing-docker-9b911eb3-3e93-4fc4-acb7-571482555639 4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 i686 i386 GNU/Linux plugin path: /snap/pharo/x1/usr/bin/pharo-vm/ [default: /snap/pharo/x1/usr/bin/pharo-vm/] Cheers, Alistair

March 17, 2017