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

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Alexandre Bergel

Try this one: https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_macos32x86… <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_macos32x86…> Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Mar 24, 2017, at 10:33 AM, webwarrior <reg(a)webwarrior.ws> wrote: > > abergel wrote >> Hi! >> >>> Image >>> ===== >>> >>> - Cairo surface crash. >> >> I may have a good news on this issue. Recently Eliot produced a new VM >> that prevents garbage collection while doing a bitblt. I have used this VM >> for a couple of days and have not experienced any crashes. >> >> Maybe this long lasting issue is solveâ¦ >> >> Alexandre > > Where can I get this new VM? Is it on files.pharo.org yet? > > > > -- > View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 24, 2017

Re: [Pharo-dev] [Vm-dev] Serial Port not working on Mac

by Esteban Lorenzano

> On 24 Mar 2017, at 15:07, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > We are here with Olivier taking a loot at how serial ports work, because he wants to use it to connect to arduino/raspberries. > > We saw that the serial port works nice in unix, in windows we had a look but we found some problems (and we do not have now a windows machine to test well), and we found that in mac it does not work. We are seeing that this behaviour is there since Pharo 3 (4 years ago). > > We tried to see if it was a problem of the VM plugin (missing depenencies using ld / otool) but everything seemed ok. > > Finally, we took the vm from git and tried to compile it from scratch. > > Meta-question 1: Is there a way to create an xcode project from the vm sources? We would have lost less time if we used a graphical debugger to take a look at this :). No. What you do is to create an empty project and then attaching the running vm. Esteban > > There, we found that > - apparently the mac VM is using an empty implementation of the serial port plugin: > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20…> > > We replaced the contents of that file by the one in the Unix plugin and it worked when the plugin was compiled as internal (delta some differences between the default values in mac and unix like uppercasing the 's' of ttyS and ttys) > > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p…> > > However, as soon as we retried to recompile the plugin as external it did not work any more... The initializeModule function was never called, the module was not loaded (from the system report) and the Serial port could not be open. For this we would have liked a debugger. And I'm not a friend of gdb on the terminal... > > Meta-question 2: Is there any clean/make clean used to remove generated files. We found ourselves a lot of times bitten by the fact that even recompiling everything using `mvm -A` did not really recompile and we had to remove files from here and there... > > How should we propose a fix? > - do we duplicate the code of the plugin in the mac and unix platforms? > - or do we somehow tell the compilation process that for this plugin it should use the sources in the unix platform code? > > Thanks! > Guille and Olivier

March 24, 2017

Serial Port not working on Mac

by Guillermo Polito

Hi all, We are here with Olivier taking a loot at how serial ports work, because he wants to use it to connect to arduino/raspberries. We saw that the serial port works nice in unix, in windows we had a look but we found some problems (and we do not have now a windows machine to test well), and we found that in mac it does not work. We are seeing that this behaviour is there since Pharo 3 (4 years ago). We tried to see if it was a problem of the VM plugin (missing depenencies using ld / otool) but everything seemed ok. Finally, we took the vm from git and tried to compile it from scratch. *Meta-question 1:* Is there a way to create an xcode project from the vm sources? We would have lost less time if we used a graphical debugger to take a look at this :). There, we found that - apparently the mac VM is using an empty implementation of the serial port plugin: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20… We replaced the contents of that file by the one in the Unix plugin and it worked *when the plugin was compiled as internal* (delta some differences between the default values in mac and unix like uppercasing the 's' of ttyS and ttys) https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/p… However, as soon as we retried to recompile the plugin as external it did not work any more... The initializeModule function was never called, the module was not loaded (from the system report) and the Serial port could not be open. For this we would have liked a debugger. And I'm not a friend of gdb on the terminal... *Meta-question 2:* Is there any clean/make clean used to remove generated files. We found ourselves a lot of times bitten by the fact that even recompiling everything using `mvm -A` did not really recompile and we had to remove files from here and there... How should we propose a fix? - do we duplicate the code of the plugin in the mac and unix platforms? - or do we somehow tell the compilation process that for this plugin it should use the sources in the unix platform code? Thanks! Guille and Olivier

March 24, 2017

Re: [Pharo-dev] Pharo Papers

by Serge Stinckwich

With Nick, we try to add the PHARO tag on some on our publications but apparently he does appear in the list. Is it updated from time to time ? Regards, On Thu, Feb 23, 2017 at 10:57 AM, denker <marcus.denker(a)inria.fr> wrote: > Hello, > > I have setup a collection at HAL. For now it is empty, we should fill it and then add it to the website > (and announce it then, not nowâ¦). > > The collection automatically has every paper on HAL that has âPHAROâ as a keyword in the field > "Project/Collaborationâ. > > https://hal.inria.fr/PHARO/ > https://hal.archives-ouvertes.fr/PHARO > > HAL is not Inria specific, here is some more infos (from https://hal.archives-ouvertes.fr ): > > HAL is an open archive where authors can deposit scholarly documents from all academic fields. > > For the attention of the authors > > â¢ The deposit must be made in agreement with the co-authors and in the respect for the policy of the publishers. > â¢ The deposit is subject of a control, HAL reserves the right to refuse items that do not meet the criteria of the archive. > â¢ Any deposit is definitive, no withdrawals will be made after the on-line posting of the publication. > â¢ Text files in pdf format or image files are sent to CINES (https://www.cines.fr/en/) for long-term archiving. > > For the attention of the readers > > â¢ In a context of electronic distribution, every author keep all its intellectual property rights. > > > > >> On 16 Feb 2017, at 15:13, denker <marcus.denker(a)inria.fr> wrote: >> >> One idea on my TODO that I got from colleagues here working on another OpenSource/Research >> system (Sofa3D): to add all publication to the website automatically using HAL (the national french >> paper database). >> >> It looks like this on the website: >> https://www.sofa-framework.org/applications/publications/ >> >> and here âhow to add a paperâ: >> >> https://www.sofa-framework.org/applications/publications/add-a-publication-… >> >> I will definitely set this up for Pharo later this year (read: as soon as possible) >> >> Marcus >> >> >>> On 16 Feb 2017, at 14:30, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> And now for your regularly scheduled random trivia show... >>> I was mildly curious about how many papers touched on Pharo. >>> >>> 1,110 on google scholar for... >>> "pharo" "programming" >>> http://tiny.cc/pharo-scholar >>> >>> 1,630 on normal google for... >>> "pharo" "programming" "abstract" "introduction" "conclusion" >>> "references" filetype:pdf >>> http://tiny.cc/pharo-papers >>> >>> Probably a lot of overlap between them. >>> cheers -ben >>> >> > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Esteban Lorenzano

> On 24 Mar 2017, at 14:33, webwarrior <reg(a)webwarrior.ws> wrote: > > abergel wrote >> Hi! >> >>> Image >>> ===== >>> >>> - Cairo surface crash. >> >> I may have a good news on this issue. Recently Eliot produced a new VM >> that prevents garbage collection while doing a bitblt. I have used this VM >> for a couple of days and have not experienced any crashes. >> >> Maybe this long lasting issue is solveâ¦ >> >> Alexandre > > Where can I get this new VM? Is it on files.pharo.org yet? yes, if you download latest you should have the fixes. Esteban > > > > -- > View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by webwarrior

abergel wrote > Hi! > >> Image >> ===== >> >> - Cairo surface crash. > > I may have a good news on this issue. Recently Eliot produced a new VM > that prevents garbage collection while doing a bitblt. I have used this VM > for a couple of days and have not experienced any crashes. > > Maybe this long lasting issue is solveâ¦ > > Alexandre Where can I get this new VM? Is it on files.pharo.org yet? -- View this message in context: http://forum.world.st/Esteban-s-list-of-blocking-issues-for-release-Pharo-6… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Esteban Lorenzano

> On 24 Mar 2017, at 14:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hi, > > I wanted to share with you the list of blocking issues I see to do the release :) > > Image > ===== > > - Cairo surface crash. > Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will > workaround the problem by adding a (hopefully temporal) CairoPlugin. > - Iceberg needs to enter the system as preview before release. > This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux > (see below). > - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our > increasing sizes. Now it works and images continue growing without control, so we need to find it. > > Image 64bits > ============ > - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, > that's not true on 64bits (at least in windows). > > VM > == > - New VM compactor has problems when image hits a big size. > Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. > - here are still some glitches and tests do not pass completely. > Methods failing in travis are: > > DelayMicrosecondSchedulerTest>>#testForMilliseconds > MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne > > This, in linux VM. I think is important but I think we will have a solution next days > - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot > rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script > as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. > Iâm testing this. > > > VM 64bits > ========= > - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes > impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) > Hi Esteban, > Doesn't the Travis build correctly succeed? > https://bintray.com/opensmalltalk/vm/cog/201703222227#files <https://bintray.com/opensmalltalk/vm/cog/201703222227#files> yes, but the PharoVM for mac in 64bits is not including libgit2 (because I was unable to compile it) :P if you (or anyone) find the time and helps me doing that, I will be very, very, very grateful (and release will be earlier ;) Esteban > > > - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to > see how is working. > > > Yes please, try stack VM for Win64. The bleeding edge pharo VM are automatically built by appveyor > https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog <https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog> > https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…> > >

March 24, 2017

Re: [Pharo-dev] ZnEasy problem?

by Sven Van Caekenberghe

Hmm, we'll have to study this better, since the following still works for me (while Stef's original URL, http://pharo.org/web/files/pharo.png, also fails for me): ZnEasy getPng: 'http://pharo.org/files/pharo.png'. This is also the URL used in the unit tests. Now, needless to say that the day Pharo cannot access its own server using TLS/SSL we are in trouble. I have warned about this before. We need to work on the SSL Plugin. Step one is the following: https://pharo.fogbugz.com/f/cases/19606/Switch-SSL-Plugin-Code-for-macOS-to… Hopefully we can do something similar for Windows, but that is out of my area of expertise. Just to be clear: this is related to TLS/SSL (Zodiac), not Zinc. The problem is probably not in the fundamental logic of encrypting/decrypting the stream, but it in the setup of the connection, most probably related to certificates. Sven > On 24 Mar 2017, at 09:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I can confirm it too on mac. > A problem in the SSL plugin? (we know is not in the best shapeâ¦ but Iâd like to know why this was working before and not it stopped). > > Esteban > >> On 24 Mar 2017, at 08:48, Ben Coman <btc(a)openInWorld.com> wrote: >> >> >> >> On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi guys >> >> in the mooc (first example) we have the following expression >> >> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') >> >> and it does not work anymore. I'm pair programming with Amal in Rennes >> from the university in italy and from her univ in Rennes >> we both get on 60 and 50 >> >> and time out https >> >> sslException: text code: code >> self error: >> (String streamContents: [ :stream | >> stream << 'SSL Exception: ' << text << ' [code:'. >> stream print: code. >> stream << ']' ]) >> >> Any idea. >> >> Tx in advance >> >> What platform are you on. >> >> On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 >> I can confirm the same error with this... >> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png'). >> >> but picking some random SSL PNG, this works fine... >> (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png'). >> >> It is strange that you are getting an SSL error using http rather than https. >> It seems the server is redirecting to http to https and maybe this is not handled? >> https://geekflare.com/http-to-https-redirection/ >> >> When was the last update to rewrite rules on the server? >> >> cheers -ben >> >> >> >

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Nicolas Cellier

2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > I wanted to share with you the list of blocking issues I see to do the > release :) > > Image > ===== > > - Cairo surface crash. > Of course, as it is now is unnaceptable... I have some solution to test > but if that does not work, I will > workaround the problem by adding a (hopefully temporal) CairoPlugin. > - Iceberg needs to enter the system as preview before release. > This is needed to use the new process, and it was almost ready but we get > blocked for a problem in VM for linux > (see below). > - I'm quite sure there is still a leak. During too much time we had the > compactor problem so we blame it for our > increasing sizes. Now it works and images continue growing without > control, so we need to find it. > > Image 64bits > ============ > - Athens is working in general, but there are still some places where it > uses a `long` as a pointer and of course, > that's not true on 64bits (at least in windows). > > VM > == > - New VM compactor has problems when image hits a big size. > Eliot is working on it, but we cannot release with VM as it is now... I > hope it will be fixed next days too. > - here are still some glitches and tests do not pass completely. > Methods failing in travis are: > > DelayMicrosecondSchedulerTest>>#testForMilliseconds > MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne > > This, in linux VM. I think is important but I think we will have a > solution next days > - Dependency libraries problem. Again, in linux... we distribute libgit2, > libssh2 and libssl (because we cannot > rely on linux installed versions), and there is a problem to solve the > paths. Ultimate solution is to use a script > as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. > Iâm testing this. > > > VM 64bits > ========= > - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one > we are using) for macOS, which makes > impossible to use Iceberg. Not sure this is blocking, but well... I > needed to point it :) > Hi Esteban, Doesn't the Travis build correctly succeed? https://bintray.com/opensmalltalk/vm/cog/201703222227#files > - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a > StackVM for windowsâ¦ I need to > see how is working. > > > Yes please, try stack VM for Win64. The bleeding edge pharo VM are automatically built by appveyor https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Alexandre Bergel

I will do a couple of more tests. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Mar 24, 2017, at 9:53 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 24 Mar 2017, at 13:27, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> Hi! >> >>> Image >>> ===== >>> >>> - Cairo surface crash. >> >> I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes. >> >> Maybe this long lasting issue is solveâ¦ > > Iâm aware of this, that was my âsolution to testâ :) > but if you can confirm it works, I will commit the image changes Eliot gave me :) > > Esteban > >> >> Alexandre

March 24, 2017