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

Re: [Pharo-dev] PharoSpur32Vm

by Nicolas Cellier

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.nice@ > gmail.com>: > >> Hi Nicolai, >> >> If you look at appveyor.yml configuration on >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/.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-proje >> ct/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. > >> 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 14, 2017

Re: [Pharo-dev] PharoSpur32Vm

by Nicolai Hess

2017-03-11 10:01 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi Nicolai, > > If you look at appveyor.yml configuration on https://github.com/ > OpenSmalltalk/opensmalltalk-vm/blob/Cog/.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- > project/pharo-vm/blob/master/.appveyor.yml and follow the scripts there. > Ok, thank you. > > 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\LoadVMMaker.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 14, 2017

Re: [Pharo-dev] image not opening.

by Eliot Miranda

On Sun, Mar 12, 2017 at 3:04 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Yeh, to be more precise, > * the problem is that the image somehow got it's display size modified to > a very small one. > * And that happenned while building an image in the CI in headless mode. > * If the same image is built locally in a vm launched in non-headless > mode, the issue cannot be reproduced. > > So my conjecture is that > - either the image is changing the display size while loading pillar (less > likely and not reproduceable locally) > - either the latest stable VM messes the display size in the image header > when running on headless (this is yet to reproduce) > I'm pretty confident this is to do with bugs in the Athens surface code which assumes that callbacks can be made in the existing copyBits and warpBits primitive. They can't do this safely because a GC (scavenge) can happen during a callback, which then causes chaos when the copyBits primitive tries to access objects that have been moved under its feet. I've done work to fix callbacks so that when there is a failure it is the copyBits primitive that fails, instead of apparently the callback return primitive. One of the apparent effects of this fix is to stop the screen opening up too small; another is getting the background colour right, and yet another is eliminating bogus pixels in the VGTigerDemo demo. But more work is required to fix the copyBits and warpBits primitives. There are a few approaches one might take: a) fixing the primitive so that it saves and restores oops around the callbacks using the external pop table. That's a pain but possible. b) fixing the primitive so that it pins the objects it needs before ever invoking a callback c) fixing the primitive so that it uses the scavenge and fullGC counters in the VM to detect if a GC occurred during one of the callbacks and would fail the primitive. The primitive would then simply be retried. d) ? I like c) as it's very lightweight, but it has issues. It is fine to use for callbacks *before* cop[yBits and warpBits move any bits (the lockSurface and querySurface functions). But it's potentially erroneous after the unlockSurface primitive. For example, a primitive which does an xor with the screen can't simply be retried as the first, falling pass, would have updated the destination bits but not displayed them via unlockSurface. But I think it could be arranged that no objects are accessed after unlockSurface, which should naturally be the last call in the primitive (or do I mean showSurface?). So the approach would be to check for GCs occurring during querySurface and lockSurface, failing if so, and then caching any and all state needed by unlockSurface and showSurface in local variables. This way no object state is accessed to make the unlockSurface and showSurface calls, and no bits are moved before the queryDurface and lockSurface calls. If we used a failure code such as #'object may move' then the primitives could answer this when a GC during callbacks is detected and then the primitive could be retried only when required. > On Sun, Mar 12, 2017 at 10:52 AM, stepharong <stepharong(a)free.fr> wrote: > >> guillermo was suspecting a problem with the interpretatin of the image >> metadata >> >> Maybe related? >>> http://forum.world.st/BUG-A-problem-with-callbacks-that-show >>> s-up-in-64bits-but-is-on-32bits-too-td4938152.html >>> >>> On Sat, Mar 11, 2017 at 2:22 AM, Cyril Ferlicot >>> <cyril.ferlicot(a)gmail.com> wrote: >>> >>>> >>>> On ven. 10 mars 2017 at 18:42, stepharong <stepharong(a)free.fr> wrote: >>>> >>>>> >>>>> We found the problem with Guillermo and this may be a problem of the >>>>> last >>>>> VM. >>>>> >>>>> The image got its starting window size really small: some pixels on >>>>> some >>>>> pixles. >>>>> So may be the metadata of the image are systematically corrupted. >>>>> >>>>> Hi >>>>> >>>>> I have a jenkins that produce an image that does not start >>>>> when I try to open it locally. >>>>> >>>>> Now if I take the image and load the "same" configuration I get a >>>>> working >>>>> image >>>>> >>>>> I have not idea how to debug that. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's mail client: http://www.opera.com/mail/ >>>>> >>>> >>>> >>>> If it can help: here is the build: >>>> >>>> https://ci.inria.fr/pharo-contribution/job/OOnoz/ >>>> >>>> It is happening in almost all Pharo 6 builds >>>> -- >>>> Cheers >>>> Cyril Ferlicot >>>> >>> >>> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > -- _,,,^..^,,,_ best, Eliot

March 14, 2017

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

by Eliot Miranda

Hi Luke, On Tue, Feb 28, 2017 at 5:11 AM, lw1990 <lukewallace1990(a)gmail.com> wrote: > Thank you all for the excellent replies > I will be rereading them, here are my thoughts/responses for now: > > There exists a windows scripting language called autohotkey > (autohotkey.com) similar to autoit, which does everything I want, I > merely > wanted to make similar functionality in Pharo so I could use Pharo - it > will > be better for large and ambitious windows projects. > > AutoHotkey is open source and the source of the language is in C. > > So, most or all of the necessary C code is hopefully already available, I > will just have to figure out how to put it into Pharo. It will not be as > ambitious as Autohotkey itself because Pharo has most of the functionality > required by default - all that is needed is DllCall's for the Windows API > to > get/set values, hooks to be aware of Windows Messages, and perhaps one day > an API to create native windows gui's using Pharo syntax. That is at least > all of the main stuff I can think of that would be useful to most business > people that want to automate their windows OS. > > Pharo offers a very good IDE/debugger and programming environment, and > natural language syntax which Autohotkey lacks. Autohotkey is the best > there > is right now, but I believe Pharo could surpass it quickly once some of > this > functionality is implemented. The number one reason Autohotkey is easy to > use is because the community is extremely responsive and helpful, and Pharo > seems to be this way too :-) > There is a complete integration of the Windows event loop in Newspeak, written by Vassili Bykov. It is implemented above the same Alien callbacks we have in Pharo and Squeak, which use slightly different, but mostly common versions of the same VM. If you're looking to integrate with Windows events I suggest contacting the newspeaklanguage group and asking there for assistance in porting the code to Pharo. -- > View this message in context: http://forum.world.st/How-to- > listen-for-microsoft-os-windows-messages-WM-MESSAGE-s- > tp4936285p4936388.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > _,,,^..^,,,_ best, Eliot

March 14, 2017

Re: [Pharo-dev] [ANN] threaded heartbeat VMs added to zeroconf

by Ben Coman

Good discussion here... http://forum.world.st/Unix-heartbeat-thread-vs-itimer-td4928943.html#a49289… cheers -ben On Tue, Mar 14, 2017 at 2:44 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Can you explain what a Threaded Heartbeat VM is? > I can do some inference based on the name, but I'll probably be wrong. > > Regards! > Esteban A. Maringolo > > > 2017-03-13 14:38 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hello, > > > > Following recent talks, I added threaded heartbeats VMs to zeroconf. > > Is weird because is not anymore âzeroâ conf: you need to configure the > > machine to accept this VMâ¦ but well, this is like that :P > > > > The links to use are this: > > > > http://get.pharo.org/vmT60 > > http://get.pharo.org/vmTLatest60 > > http://get.pharo.org/alpha+vmT > > http://get.pharo.org/alpha+vmTLatest > > http://get.pharo.org/60+vmTLatest > > > > (they are listed at http://get.pharo.org, as usual) > > > > cheers, > > Esteban > > > >

March 13, 2017

Re: [Pharo-dev] [ANN] threaded heartbeat VMs added to zeroconf

by Esteban A. Maringolo

Can you explain what a Threaded Heartbeat VM is? I can do some inference based on the name, but I'll probably be wrong. Regards! Esteban A. Maringolo 2017-03-13 14:38 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hello, > > Following recent talks, I added threaded heartbeats VMs to zeroconf. > Is weird because is not anymore âzeroâ conf: you need to configure the > machine to accept this VMâ¦ but well, this is like that :P > > The links to use are this: > > http://get.pharo.org/vmT60 > http://get.pharo.org/vmTLatest60 > http://get.pharo.org/alpha+vmT > http://get.pharo.org/alpha+vmTLatest > http://get.pharo.org/60+vmTLatest > > (they are listed at http://get.pharo.org, as usual) > > cheers, > Esteban >

March 13, 2017

Re: [Pharo-dev] [ANN] Fog - Ethereum driver

by Esteban A. Maringolo

Very Nice! Thank you for building it. I started a similar project for the Bitcoin blockchain, but then I drifted away and never got back to it. Are you writing DAPPs? Best regards, Esteban A. Maringolo 2017-03-13 12:00 GMT-03:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > Hi all. Im happy to announce a pre release of the Fog ethereum driver that > we develop in the space of an Inria project. > > It still not complete but is already usable for some experiments and simple > projects. > > You can downloadit from > https://github.com/sbragagnolo/Fog/ > (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1) > > Dependencies > > RHash > > sudo apt-get install rhash > > Solidity > > npm install solc > > Download code > > Iceberg / Baseline > > Metacello > new > baseline: 'Fog'; > repository: 'github://sbragagnolo/Fog:v0.1.1.1/src'; > load. > > By hand > > You may want to use this version for having access to some scripts and > contracts samples. > > git checkout git@github.com:sbragagnolo/Fog.git > > git checkout v0.1.1.1 > > Metacello > new > baseline: 'Fog'; > repository: 'filetree:///path/to/git-repository/Fog/src';; > load. > > > It's based on the standar API for javascript > (https://github.com/ethereum/wiki/wiki/JavaScript-API) . > > It provides interaction with remote contracts, it do as well provides a way > for navigating the architecture objects: blocks, transactions, accounts and > contracts. > > I hope you find it useful. > > Feel free to fill the github issue tracker with anything you find :). > > > I will come to you with some new exciting news about ethereum soon :) > > Santiago. > > > > > >

March 13, 2017

Re: [Pharo-dev] [ANN] threaded heartbeat VMs added to zeroconf

by Thierry Goubier

Thanks Esteban! (well, on Linux, the 32 bits VM were not zero-conf either, far from it) Thierry Le 13/03/2017 Ã 18:38, Esteban Lorenzano a Ã©crit : > Hello, > > Following recent talks, I added threaded heartbeats VMs to zeroconf. > Is weird because is not anymore âzeroâ conf: you need to configure the > machine to accept this VMâ¦ but well, this is like that :P > > The links to use are this: > > http://get.pharo.org/vmT60 > http://get.pharo.org/vmTLatest60 > http://get.pharo.org/alpha+vmT > http://get.pharo.org/alpha+vmTLatest > http://get.pharo.org/60+vmTLatest > > (they are listed at http://get.pharo.org, as usual) > > cheers, > Esteban >

March 13, 2017

[ANN] threaded heartbeat VMs added to zeroconf

by Esteban Lorenzano

Hello, Following recent talks, I added threaded heartbeats VMs to zeroconf. Is weird because is not anymore âzeroâ conf: you need to configure the machine to accept this VMâ¦ but well, this is like that :P The links to use are this: http://get.pharo.org/vmT60 http://get.pharo.org/vmTLatest60 http://get.pharo.org/alpha+vmT http://get.pharo.org/alpha+vmTLatest http://get.pharo.org/60+vmTLatest <http://get.pharo.org/60+vmTLatest> (they are listed at http://get.pharo.org <http://get.pharo.org/>, as usual) cheers, Esteban

March 13, 2017

Pharo6 supported syntax regression

by Peter Uhnak

Hi, apparently in Pharo 6 pragma attributes can no longer be symbols without hash? In Pharo5 I could do method <attr: Something> and it would compile it as symbol In Pharo6 this is syntax error. I am not asking for resolution either direction (although I guess #Something should be canonical), it is just odd to me that the syntax would change (and maybe some code where people like me forgot to add hash sign will break). Peter

March 13, 2017