- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo6 64bits Unix on Windows 10

by Thierry Goubier

Le 28/11/2016 Ã 18:00, Henrik Nergaard a Ã©crit : > Do you mean starting a linux vm via windows-bash with DISPLAY exported > to something like xming, or was something else done? Windows bash with Xming as display, yes. > - fetching packages from github. (tar fail to create files with ':' in > them, so downloading filetree from github fails). > > > > If the image/download path is located within the âunix file systemâ > instead of â/mnt/c/*â then unpacking files containing $: should work. Noted. This could be it. > Downloading the .zip + unzipping instead of cloning the repo works but > it will replace the $: with $_. I choose to download a tgz because you can't unzip on a pipe. In that particular case, replacing $: by $_ wouldn't be an issue. > There is also the possibility to do this modification by downloading the > .zip into memory and âpatchingâ the filename / install without using the > file system at all. > ZipArchive new readFrom: âhttps://gitbub.com/â¦/..zipâ asZnUrl > retrieveContents readStream. A bit overkill for the fact that simply unzipping would work. > Best regards, Thanks. I can provide the Makefile used, if anyone is interested. Thierry > Henrik > > > > > > *From:*Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Thierry Goubier > *Sent:* Monday, November 28, 2016 4:26 PM > *To:* Pharo <pharo-dev(a)lists.pharo.org> > *Subject:* [Pharo-dev] Pharo6 64bits Unix on Windows 10 > > > > Hi guys, > > Jason Lecerf, a new PhD student at CEA, has managed to run a Pharo6 > 64bits vm and image (60307) under the ubuntu add-ons to Microsoft > Windows 10. > > What is validated is: > > - downloading the latest 64bits pharo vm from esteban > > - downloading the latest image from files.pharo.org <http://files.pharo.org> > > - opening the gui. > > What doesn't work well > > - fetching packages from github. (tar fail to create files with ':' in > them, so downloading filetree from github fails). > > > > As far as I know of the process, running a 32bits image and vm should > work too. > > Thierry >

Nov. 28, 2016

Re: [Pharo-dev] Pharo6 64bits Unix on Windows 10

by Henrik Nergaard

Do you mean starting a linux vm via windows-bash with DISPLAY exported to something like xming, or was something else done? - fetching packages from github. (tar fail to create files with ':' in them, so downloading filetree from github fails). If the image/download path is located within the âunix file systemâ instead of â/mnt/c/*â then unpacking files containing $: should work. Downloading the .zip + unzipping instead of cloning the repo works but it will replace the $: with $_. There is also the possibility to do this modification by downloading the .zip into memory and âpatchingâ the filename / install without using the file system at all. ZipArchive new readFrom: âhttps://gitbub.com/â¦/..zipâ asZnUrl retrieveContents readStream. Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Thierry Goubier Sent: Monday, November 28, 2016 4:26 PM To: Pharo <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] Pharo6 64bits Unix on Windows 10 Hi guys, Jason Lecerf, a new PhD student at CEA, has managed to run a Pharo6 64bits vm and image (60307) under the ubuntu add-ons to Microsoft Windows 10. What is validated is: - downloading the latest 64bits pharo vm from esteban - downloading the latest image from files.pharo.org<http://files.pharo.org> - opening the gui. What doesn't work well - fetching packages from github. (tar fail to create files with ':' in them, so downloading filetree from github fails). As far as I know of the process, running a 32bits image and vm should work too. Thierry

Nov. 28, 2016

Pharo6 64bits Unix on Windows 10

by Thierry Goubier

Hi guys, Jason Lecerf, a new PhD student at CEA, has managed to run a Pharo6 64bits vm and image (60307) under the ubuntu add-ons to Microsoft Windows 10. What is validated is: - downloading the latest 64bits pharo vm from esteban - downloading the latest image from files.pharo.org - opening the gui. What doesn't work well - fetching packages from github. (tar fail to create files with ':' in them, so downloading filetree from github fails). As far as I know of the process, running a 32bits image and vm should work too. Thierry

Nov. 28, 2016

[IMPORTANT] TechTalk from November postponed to Dec 13... and it will be around iceberg

by Esteban Lorenzano

Hello, We will postpone the TechTalk for two weeks, to Dec 13 16h UTC because two reasons: 1) There will not be a âDecember talkâ, because last tuesday of the month will be 27 and is unreal to pretend people will be around :) 2) We want to talk about iceberg and we believe is so important that we want to maximise participants/questions/etc. 2.1) â¦ and we just missed the date (who was tomorrow) and we are not prepared :) Iâm sorry for the inconvenience, I hope you can all make it and be there... cheers, Esteban

Nov. 28, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by Ronie Salgado

Now I found the FFI problem with MinGW , I was missing some old compilation flags on my CMake scripts. I still have to fix this same bug with MSVC, but at least normal Pharo image can eval "1+1" without crashing, and stdout is working properly now in Windows. During the rest of the week I will make this VM variant working completely on Linux, Windows and OS X, with SDL2 and hopefully we will get OSWindow working alot better in Windows and Mac. (In Linux it was already working pretty well, probably because each X connection has its own event queue). Interesting to note Microsoft is moving to Clang [1] to replace their > C1 front-end, which should(?) make cross-platform with OSX and Linux a > bit easier. Anyone know if that means MVSC might be better to use on > its own than using MinGW/Cygwin? > > [1] http://www.theregister.co.uk/2015/10/21/microsoft_promises_ > clang_for_windows_in_november_visual_c_update/ > > cheers -ben In Windows the standard compiler is MSVC, despite it has a poorer quality than gcc/clang. The movement to the clang front-end is something where it is not possible to rely until it becomes stable. It is quite clear that the VM is not meant to be used with MSVC, because it is not being built and tested with it all of the time. However, in some platforms, the only alternative is MSVC. Best regards, Ronie 2016-11-28 0:46 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > > On Mon, Nov 28, 2016 at 5:01 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > > > Ronie, > > > > Is all of this in a branch somewhere so that I can have a look? > > > > For cairo, I think that I can build it with another compiler than MinGW, > it doesn't really matter as it just makes a dll (or well, I can just skip > that and reuse an already built one). > > > > -ltro is the flag that makes the whole thing trips up in GCC5 and > requires additional flags, but adding them just kicked the can down the > road a bit further as they were still unresolved symbols. Need to see why > cairo build gives that but seems a cairo issue that others are facing as > well. May end up building cairo with the old compiler but this defeats the > purpose. > > > > For VS2015, I've got it too and yes, the debugging facilities are much > better, not to mention that the compilation times are much nicer. GCC is > just dog slow on Windows compared to Linux. I read that it was because of > sub-bar fork support in Windows. > > Interesting to note Microsoft is moving to Clang [1] to replace their > C1 front-end, which should(?) make cross-platform with OSX and Linux a > bit easier. Anyone know if that means MVSC might be better to use on > its own than using MinGW/Cygwin? > > [1] http://www.theregister.co.uk/2015/10/21/microsoft_promises_ > clang_for_windows_in_november_visual_c_update/ > > cheers -ben >

Nov. 28, 2016

Re: [Pharo-dev] Bloc: Problems Running

by Aliaksei Syrel

Hi Bloc requires an additional library that is not shipped with VM by default (that is why you get module not found error). Please refer to https://github.com/pharo-graphics/Bloc/blob/master/INSTALL.md in order to install bloc. Cheers Alex On Nov 28, 2016 03:49, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > From Launcher, I tried to expand the v0.11 tree from the Contribution > Jenkins, but got: "downloadFailureForUrl: > https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO= > 60,VERSION=v0.11,VM=vm,label=pharo-contribution-ubuntu16- > 04/lastSuccessfulBuild//api/json?tree=artifacts%5BrelativePath%5D". > Then I downloaded the "master" artifact and on image launch, got "Error: > External module not found" for SqueakFFIPrims even though it's listed as a > builtin module in the System Reporter. I got the same error when I evaled > "BlSpace new show". The vm is a recent download from get.pharo.org/vm50 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bloc- > Problems-Running-tp4924930.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Nov. 28, 2016

Bloc: Problems Running

by Sean P. DeNigris

>From Launcher, I tried to expand the v0.11 tree from the Contribution Jenkins, but got: "downloadFailureForUrl: https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=60,VERSION=v0.11,VM=v…". Then I downloaded the "master" artifact and on image launch, got "Error: External module not found" for SqueakFFIPrims even though it's listed as a builtin module in the System Reporter. I got the same error when I evaled "BlSpace new show". The vm is a recent download from get.pharo.org/vm50 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Problems-Running-tp4924930.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 28, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by Ronie Salgado

Hi Phil, It is on the MinimalisticHeadless branch of ( https://github.com/ronsaldo/opensmalltalk-vm/tree/MinimalisticHeadless ). With VS you are going to receive a lot of messages such as: > GIV(remapBufferCount) == 0 55758 > These are false positives due to the macro expansion bug. > Nice to give me an excuse to get an XBox One for XMas in order to try > Pharo on it. > For me it is also an excuse for XMas ;) . Best regards, Ronie 2016-11-27 18:01 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > Ronie, > > Is all of this in a branch somewhere so that I can have a look? > > For cairo, I think that I can build it with another compiler than MinGW, > it doesn't really matter as it just makes a dll (or well, I can just skip > that and reuse an already built one). > > -ltro is the flag that makes the whole thing trips up in GCC5 and requires > additional flags, but adding them just kicked the can down the road a bit > further as they were still unresolved symbols. Need to see why cairo build > gives that but seems a cairo issue that others are facing as well. May end > up building cairo with the old compiler but this defeats the purpose. > > For VS2015, I've got it too and yes, the debugging facilities are much > better, not to mention that the compilation times are much nicer. GCC is > just dog slow on Windows compared to Linux. I read that it was because of > sub-bar fork support in Windows. > > Nice to give me an excuse to get an XBox One for XMas in order to try > Pharo on it. > > Best, > Phil > > > > On Sat, Nov 26, 2016 at 11:16 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Hi, >> >> I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under >>> Mingw). >>> If you have a GCC5 instead of the old 4.6, I am interested in your >>> config. >>> >> Now I am building in Windows using both, MinGW version 4.9.3, and Visual >> Studio 2015 Community Edition. >> >> I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the >> -headless parameter is for the image to quit after finishing). >> When running a normal Pharo.image, I am getting a FFI related crash (with >> Visual Studio and MinGW), when the image tries to read the APPDATA >> environment variable. >> >> Right now I am using the same main function for both, the Unix and Win32 >> VM. This means, that we are close of having the embedded version. >> >> In windows I am build two variants of the VM, pharo.exe (or squeak.exe) >> and pharow.exe (or squeakw.exe). The executable without the w is a console >> program, so it can use stdin, stdout and stderr. The executable with the w >> is a windows program that does not create a console window on startup, but >> it cannot use stdout, stderr, or stdin. This is the standard workaround for >> an annoying limitation of Windows itself (Python does the same in windows, >> with the same nomenclature). >> >> Visual Studio is unstable than MinGW, but it has an excellent debugger. >> With Visual Studio, I am getting some false positives for an assertion >> because they get miscompiled. For some reason, the >> assert(GIV(remapBufferCount) == 0) gets compiled into the same as >> assert(GIV(remapBufferCount)). Apart from this assertion, these two >> versions of the VM are crashing in the same place. >> >> >>> Fantastic, except: >>> >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >>> want to use them in Windows too. >>> >>> >>> We have agreed that we will use makefiles and restrict make to >>> generating platform config.h files that define platform facilities. I have >>> very good reasons for doing this. I have discussed this at length this >>> year. Please don't make me argue this all over again. >>> ... >>> [goodness deleted] >>> >> I cannot just use makefile, because I am also compiling in Windows using >> Visual Studio 2015 Community Edition, by generating the visual studio >> projects with CMake. I looked for the older discussions on the mailing >> lists, I could not find, a long discussion on the mailing list, except for >> several short ones. >> I have also seen some projects(LLVM, Boost) that have more than one build >> system, an official based on autoconf(or something else), and an >> alternative based on CMake. >> >> As for the config.h, I can also generate it using CMake, and I will start >> doing it now because I think that it is related to the FFI crashing issues >> that I am experimenting on Windows. Currently I am already using CMake for >> generating the git version string. As long as git is in the path and cmake >> founds it, the header with the version string is generated correctly, even >> when using the Visual Studio projects. >> >> Anyway, I am not using the old CMakeVMMaker that Igor did(and I just >> learned about Ian CMake work by finding in the mailing list). I just >> adapted the plain CMake scripts that I normally use for building my own >> projects to build the VM. >> >> Are you on board? Would you like to discuss this on skype or somewhere? >> >> Sure we can discuss it, I am on chile so we are not far apart in time >> zones. >> >> As long as building the VM can be done automatically in Unixes by running >> a short number of commands, that work most of the time, I am OK with it. >> As for Windows, it has to be possible to use Visual Studio in addition to >> MinGW or Cygwin. Visual Studio is required to be able to build for the >> Universal Windows Platform, and getting the VM working in a retail XBox One >> ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index ). >> >> Best regards, >> Ronie >> >> 2016-11-26 14:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Hi Roni, >>> >>> >>> On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: >>> >>> Hello, >>> >>> I am working on removing most of windowing code from the VM, and in >>> trying to unify the platform specific code of the VM. In the >>> MinimalistHeadless branch of https://github.com/ronsaldo/op >>> ensmalltalk-vm I made the following changes: >>> >>> >>> Fantastic, except: >>> >>> >>> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >>> want to use them in Windows too. >>> >>> >>> We have agreed that we will use makefiles and restrict make to >>> generating platform config.h files that define platform facilities. I have >>> very good reasons for doing this. I have discussed this at length this >>> year. Please don't make me argue this all over again. Are you on board? >>> Would you like to discuss this on skype or somewhere? >>> ... >>> [goodness deleted] >>> >>> Does it make sense, to always trying to create a display in startup time? >>> >>> >>> Good question. The answer should be "no" but that only makes sense if >>> the system is written to not depend on a display when in headless mode. >>> >>> >>> Best regards, >>> Ronie >>> >>> >>> >> > >

Nov. 27, 2016

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

by phil＠highoctane.be

Ronie, Is all of this in a branch somewhere so that I can have a look? For cairo, I think that I can build it with another compiler than MinGW, it doesn't really matter as it just makes a dll (or well, I can just skip that and reuse an already built one). -ltro is the flag that makes the whole thing trips up in GCC5 and requires additional flags, but adding them just kicked the can down the road a bit further as they were still unresolved symbols. Need to see why cairo build gives that but seems a cairo issue that others are facing as well. May end up building cairo with the old compiler but this defeats the purpose. For VS2015, I've got it too and yes, the debugging facilities are much better, not to mention that the compilation times are much nicer. GCC is just dog slow on Windows compared to Linux. I read that it was because of sub-bar fork support in Windows. Nice to give me an excuse to get an XBox One for XMas in order to try Pharo on it. Best, Phil On Sat, Nov 26, 2016 at 11:16 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > Hi, > > I am fighting Window VM compilation issues (e.g. Cairo with GCC5.x under >> Mingw). >> If you have a GCC5 instead of the old 4.6, I am interested in your config. >> > Now I am building in Windows using both, MinGW version 4.9.3, and Visual > Studio 2015 Community Edition. > > I got working pharo,exe -headless Pharo-minimal.image eval "1+1" (the > -headless parameter is for the image to quit after finishing). > When running a normal Pharo.image, I am getting a FFI related crash (with > Visual Studio and MinGW), when the image tries to read the APPDATA > environment variable. > > Right now I am using the same main function for both, the Unix and Win32 > VM. This means, that we are close of having the embedded version. > > In windows I am build two variants of the VM, pharo.exe (or squeak.exe) > and pharow.exe (or squeakw.exe). The executable without the w is a console > program, so it can use stdin, stdout and stderr. The executable with the w > is a windows program that does not create a console window on startup, but > it cannot use stdout, stderr, or stdin. This is the standard workaround for > an annoying limitation of Windows itself (Python does the same in windows, > with the same nomenclature). > > Visual Studio is unstable than MinGW, but it has an excellent debugger. > With Visual Studio, I am getting some false positives for an assertion > because they get miscompiled. For some reason, the > assert(GIV(remapBufferCount) == 0) gets compiled into the same as > assert(GIV(remapBufferCount)). Apart from this assertion, these two > versions of the VM are crashing in the same place. > > >> Fantastic, except: >> >> >> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >> want to use them in Windows too. >> >> >> We have agreed that we will use makefiles and restrict make to generating >> platform config.h files that define platform facilities. I have very good >> reasons for doing this. I have discussed this at length this year. Please >> don't make me argue this all over again. >> ... >> [goodness deleted] >> > I cannot just use makefile, because I am also compiling in Windows using > Visual Studio 2015 Community Edition, by generating the visual studio > projects with CMake. I looked for the older discussions on the mailing > lists, I could not find, a long discussion on the mailing list, except for > several short ones. > I have also seen some projects(LLVM, Boost) that have more than one build > system, an official based on autoconf(or something else), and an > alternative based on CMake. > > As for the config.h, I can also generate it using CMake, and I will start > doing it now because I think that it is related to the FFI crashing issues > that I am experimenting on Windows. Currently I am already using CMake for > generating the git version string. As long as git is in the path and cmake > founds it, the header with the version string is generated correctly, even > when using the Visual Studio projects. > > Anyway, I am not using the old CMakeVMMaker that Igor did(and I just > learned about Ian CMake work by finding in the mailing list). I just > adapted the plain CMake scripts that I normally use for building my own > projects to build the VM. > > Are you on board? Would you like to discuss this on skype or somewhere? > > Sure we can discuss it, I am on chile so we are not far apart in time > zones. > > As long as building the VM can be done automatically in Unixes by running > a short number of commands, that work most of the time, I am OK with it. > As for Windows, it has to be possible to use Visual Studio in addition to > MinGW or Cygwin. Visual Studio is required to be able to build for the > Universal Windows Platform, and getting the VM working in a retail XBox One > ( https://msdn.microsoft.com/en-us/windows/uwp/xbox-apps/index ). > > Best regards, > Ronie > > 2016-11-26 14:09 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi Roni, >> >> >> On Nov 23, 2016, at 11:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: >> >> Hello, >> >> I am working on removing most of windowing code from the VM, and in >> trying to unify the platform specific code of the VM. In the >> MinimalistHeadless branch of https://github.com/ronsaldo/opensmalltalk-vm >> I made the following changes: >> >> >> Fantastic, except: >> >> >> - Unified standard CMake building scripts for Unixes. I hate autoconf. I >> want to use them in Windows too. >> >> >> We have agreed that we will use makefiles and restrict make to generating >> platform config.h files that define platform facilities. I have very good >> reasons for doing this. I have discussed this at length this year. Please >> don't make me argue this all over again. Are you on board? Would you like >> to discuss this on skype or somewhere? >> ... >> [goodness deleted] >> >> Does it make sense, to always trying to create a display in startup time? >> >> >> Good question. The answer should be "no" but that only makes sense if >> the system is written to not depend on a display when in headless mode. >> >> >> Best regards, >> Ronie >> >> >> >

Nov. 27, 2016

Re: [Pharo-dev] pillar latex and code listings

by Damien Pollet

EnterprisePharo is on master and there have been few LaTeX-level changes recently. The parent commit of master dates from april when we migrated a few books, and the recent commit was documentation. I think at a minimum you'll have to use a different latex exporter in the pillar.conf (check EnterprisePharo for that) to output the sbabook-specific environments and macros, but if there are problems beyond that it's a matter of how the main file and the templates are combined. At this point my recommendation would be to migrate to the makefile-centric build of EnterprisePharo. I've just tried to build PBE but the VM that ./download.sh gets crashesâ¦ On 27 November 2016 at 12:32, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-11-21 15:17 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: > >> I finally remembered to have a quick lookâ¦ there is one named and >> referenced script in the Pillar chapter in EnterprisePharo. Look for >> occurrences of "my script" >> > > Ok, thank you Damien. > > What is the most "stable" :-) version of sbabook ? > PharoByExample uses sbabook @ b1ad4b4 > <https://github.com/cdlm/sbabook/tree/b1ad4b4f9a2ac2b2b6ae0a16f03e68e4d22ff5…> > EnterprisePharo uses sbabook @ bf4509f > <https://github.com/cdlm/sbabook/tree/bf4509fa87b1987f6f9a49edddb4e2ac9910b9…> > > nicolai > > >> >> On 13 November 2016 at 22:53, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >>> >>> >>> 2016-11-13 22:16 GMT+01:00 Damien Pollet <damien.pollet(a)gmail.com>: >>> >>>> On 13 November 2016 at 16:23, Nicolai Hess <nicolaihess(a)gmail.com> >>>> wrote: >>>> >>>>> Hi Damien, I don't see how the layout from the EnterprisePharo could >>>>> do labeled listings we could ref from the text. May it be that this is just >>>>> not possible ? >>>> >>>> >>>> I recall we discussed choices with the other Damien, and that there >>>> were constraints due to listings.sty, but I think that's possible. I'd have >>>> to have a look at the code, though, because it's very well possible that we >>>> decided on a workaround instead. >>>> >>>> Can you catch me on Slack sometime this week, or open an issue on >>>> https://github.com/cdlm/sbabook if not? >>>> >>> >>> Ok, thanks. >>> >>> >>> >>>> >>>> >>>> >>>> -- >>>> Damien Pollet >>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>> >>> >>> >>> >>> >>> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 27, 2016