- Pharo-dev - lists.pharo.org

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

by Ben Coman

On Sat, Mar 25, 2017 at 5:17 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-03-24 17:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> >> >> >> 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 >> > >> > 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 ;) >> >> Do you mean build libgit2 standalone? or as part of pharo-vm build? >> >> I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I >> could upgrade to try if needed. >> I don't know about the rpath warning. I ignored it. >> >> Standalone... >> >> 502 mkdir LIBGIT >> 503 cd LIBGIT/ >> 504 git clone https://github.com/libgit2/libgit2.git >> 505 cd libgit2 >> 521 git checkout v0.23.0 >> 522 mkdir ../build && cd ../build >> 525 cmake ../libgit2 >> -- Configuring done >> CMake Warning (dev): >> Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run >> "cmake >> --help-policy CMP0042" for policy details. Use the cmake_policy command >> to >> set the policy and suppress this warning. >> MACOSX_RPATH is not specified for the following targets: >> git2 >> >> 526 cmake --build . >> 528 file libgit2.0.23.0.dylib >> libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library >> x86_64 >> >> 529 cmake --version >> cmake version 3.0.0 >> >> 530 uname -a >> Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: >> Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 >> x86_64 >> > > Same for me here on OSX 10.11.6 El Capitan, > libgit2 builds out of the box, same warning for RPATH > Maybe we could reactivate on travis? Is this relevant regarding using ssh with using libgit ? https://github.com/libgit2/libgit2/issues/2665 cheers -ben

March 25, 2017

Re: [Pharo-dev] ZnEasy problem?

by Ben Coman

On Sat, Mar 25, 2017 at 2:04 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Some further notes. > > > On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > 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. > > Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. > Still it is good to known that at least for examples/demos/tests we still have it. > > > 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. > > I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine. > > ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'. > > Testing our failing URL and this succeeding URL using curl on macOS, I see the following: > > $ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null > * TCP_NODELAY set > * Connected to audio359.eu (146.185.177.20) port 443 (#0) > * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > * Server certificate: audio359.eu > * Server certificate: Let's Encrypt Authority X3 > * Server certificate: DST Root CA X3 > > GET /img/audio359-main-800.jpg HTTP/1.1 > ... > > vs. > > $ curl -v https://pharo.org/web/files/pharo.png > /dev/null > * TCP_NODELAY set > * Connected to pharo.org (104.28.26.35) port 443 (#0) > * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > * Server certificate: sni25155.cloudflaressl.com > * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 > * Server certificate: COMODO ECC Certification Authority > > GET /web/files/pharo.png HTTP/1.1 > ... > > I see 2 differences: > > - a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA > - at least an indication of SNI (server name identification) being used > > I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved). For Cloudflare customers at the free level of service Sites using UniversalSSL are issued SHA2+ECDSA certificates, which require clients that support TLSv1.2 and SNI. For customers at a paid level of service Cloudflare's server configuration for TLS cipher suites is set in nginx (which we use extensively) with the following configuration command: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suit… The Real Cost of a CloudFlare âFreeâ SSL Certificate https://info.ssl.com/the-real-cost-of-a-cloudflare-free-ssl-certificate/ SSL on my free plan isn't working on an old OS/Browser https://support.cloudflare.com/hc/en-us/articles/204144518-SSL-FAQ cheers -ben > > > > 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 17:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > >> > >> 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 > > > > 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 ;) > > Do you mean build libgit2 standalone? or as part of pharo-vm build? > > I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I > could upgrade to try if needed. > I don't know about the rpath warning. I ignored it. > > Standalone... > > 502 mkdir LIBGIT > 503 cd LIBGIT/ > 504 git clone https://github.com/libgit2/libgit2.git > 505 cd libgit2 > 521 git checkout v0.23.0 > 522 mkdir ../build && cd ../build > 525 cmake ../libgit2 > -- Configuring done > CMake Warning (dev): > Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run > "cmake > --help-policy CMP0042" for policy details. Use the cmake_policy command > to > set the policy and suppress this warning. > MACOSX_RPATH is not specified for the following targets: > git2 > > 526 cmake --build . > 528 file libgit2.0.23.0.dylib > libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library > x86_64 > > 529 cmake --version > cmake version 3.0.0 > > 530 uname -a > Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: > Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 > x86_64 > > Same for me here on OSX 10.11.6 El Capitan, libgit2 builds out of the box, same warning for RPATH Maybe we could reactivate on travis? > Should I be testing something else? > > cheers -ben > >

March 24, 2017

Is this a report for an announcement?

by Eliot Miranda

Hi All, there's probably no issue here, except that I'm seeing a report for an announcement, and I fear it might be wasted effort. So can someone who understands this examine the following and check whether announcements are being reported by mistake? This is an a 6.0 image with Scorch loaded (so it may be completely irrelevant). [0mProcess>>terminate NECController>>stopCompletionDelay NECController>>closeMenu MessageSend>>value MessageSend>>cull: MessageSend>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] FullBlockClosure(BlockClosure)>>on:do: FullBlockClosure(BlockClosure)>>on:fork: AnnouncementSubscription>>deliver: [ "Ensure delivery to remaining announcements" subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ "Ensure delivery to remaining announcements" sub...etc... FullBlockClosure(BlockClosure)>>ifCurtailed: SubscriptionRegistry>>deliver:to:startingAt: SubscriptionRegistry>>deliver:to: SubscriptionRegistry>>deliver: Announcer>>announce: RubEditingArea(Morph)>>doAnnounce: RubEditingArea(Morph)>>announceKeyboardFocusChange: RubEditingArea(Morph)>>keyboardFocusChange: RubEditingArea(RubAbstractTextArea)>>keyboardFocusChange: HandMorph>>newKeyboardFocus: HandMorph>>releaseKeyboardFocus [ :hand | hand releaseKeyboardFocus ] in WorldMorph>>viewBox: in Block: [ :hand | hand releaseKeyboardFocus ] Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldMorph>>viewBox: WorldMorph(PasteUpMorph)>>restoreMorphicDisplay WorldMorph class>>startUp WorldMorph class(Behavior)>>startUp: ClassSessionHandler>>startup: [0m _,,,^..^,,,_ best, Eliot

March 24, 2017

Re: [Pharo-dev] ZnEasy problem?

by Sven Van Caekenberghe

Some further notes. > On 24 Mar 2017, at 14:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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. Of course that one works, because it does not do a redirect from HTTP to HTTPS, duh. Still it is good to known that at least for examples/demos/tests we still have it. > 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. I took a file from one of my servers that it up to date and well configured (nginx, let's encrypt certificate). That works fine. ZnEasy getJpeg: 'https://audio359.eu/img/audio359-main-800.jpg'. Testing our failing URL and this succeeding URL using curl on macOS, I see the following: $ curl -v https://audio359.eu/img/audio359-main-800.jpg > /dev/null * TCP_NODELAY set * Connected to audio359.eu (146.185.177.20) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: audio359.eu * Server certificate: Let's Encrypt Authority X3 * Server certificate: DST Root CA X3 > GET /img/audio359-main-800.jpg HTTP/1.1 ... vs. $ curl -v https://pharo.org/web/files/pharo.png > /dev/null * TCP_NODELAY set * Connected to pharo.org (104.28.26.35) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 * Server certificate: sni25155.cloudflaressl.com * Server certificate: COMODO ECC Domain Validation Secure Server CA 2 * Server certificate: COMODO ECC Certification Authority > GET /web/files/pharo.png HTTP/1.1 ... I see 2 differences: - a different cipher suite (combination of algorithms used) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 vs. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with the key differences being RSA vs ECDSA - at least an indication of SNI (server name identification) being used I guess we have no control over how our website is served, since the CMS used (and cloud flare CDN being involved). > 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 webwarrior

EstebanLM wrote >> 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 Tried it. Now Pharo doesn't crash, but merely gives the following error in BitBlt>>copyBits method: Error: Bad BitBlt arg (Fraction?); proceed to convert. I don't see any Fractions, though destX and destY are Floats. If I proceed, image becomes kinda unresponsive, but can be interrupted using alt+. -- 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 Ben Coman

On Fri, Mar 24, 2017 at 9:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 2017-03-24 11:29 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> 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 > > 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 ;) Do you mean build libgit2 standalone? or as part of pharo-vm build? I dug out my old mac-mini to try. Its an older OSX Version 10.9.5. I could upgrade to try if needed. I don't know about the rpath warning. I ignored it. Standalone... 502 mkdir LIBGIT 503 cd LIBGIT/ 504 git clone https://github.com/libgit2/libgit2.git 505 cd libgit2 521 git checkout v0.23.0 522 mkdir ../build && cd ../build 525 cmake ../libgit2 -- Configuring done CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning. MACOSX_RPATH is not specified for the following targets: git2 526 cmake --build . 528 file libgit2.0.23.0.dylib libgit2.0.23.4.dylib: Mach-O 64-bit dynamically linked shared library x86_64 529 cmake --version cmake version 3.0.0 530 uname -a Darwin bens-mac-mini.home.gateway 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 Should I be testing something else? cheers -ben

March 24, 2017

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