December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] stfx.eu down

by Sven Van Caekenberghe

> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). > > This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. > For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. > > The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. > > Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. > > Sorry for the inconvenience. > > Sven > > >

Dec. 11, 2018

Re: [Pharo-dev] Playground "remote publish" feedback from discord

by Sven Van Caekenberghe

Ben could you please OK the PR ? > On 9 Dec 2018, at 13:13, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sun, 9 Dec 2018 at 18:31, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 8 Dec 2018, at 17:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Maybe an additional menu item somewhere ? > > Or a little bit more API. > > Right now with the standard GT infrastructure in Pharo 7 (and Pharo 6.1 also I guess), you can do > > GTPlayground openOn: (GTPlayPage loadFromPublishUrl: 'http://ws.stfx.eu/1WS4U'). > > We could add one of the following > > GTPlayground loadFromPublishUrl: 'http://ws.stfx.eu/1WS4U'. "keeps the same selector" > GTPlayground openPublishUrl: 'http://ws.stfx.eu/1WS4U'. "shorter, more in line with the opening action" > GTPlayground openUrl: 'http://ws.stfx.eu/1WS4U'. "the original on ZnWorkspace, shortest" > > The last is easiest to remember - composed of just two words rather than three or four.. > > > If we agree, I can change the default instructions on the web page as seen in a browser. > > There is little point in wanting to keep the ZnWorkspace code, as it is no longer needed. > > okay. > > cheers -ben

Dec. 11, 2018

Re: [Pharo-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Nicolas Cellier

And if you are using https://github.com/astares/Pharo-OS-Windows/blob/master/src/OS-Windows-Envi… rather than the OSProcess plugin, then it's a bit more involved to make the changes, because you must also redirect the I/O thru a pipe, but it's doable too. Le mar. 11 dÃ©c. 2018 Ã 14:43, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > I've checked: it's a one liner to be changed in > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win3… > near line 826 > Since this is generated code from VMMaker, the code has to be changed in > slang. > IMO, there should be a boolean argument (optional) telling if we want to > open the console or not. > IMO false by default would be a good thing, though true for backward > compatibility is also a possible alternative... > > Le mar. 11 dÃ©c. 2018 Ã 12:56, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > >> It is possible, ask stack overflow >> >> https://stackoverflow.com/questions/4743559/how-to-execute-child-console-pr… >> >> https://stackoverflow.com/questions/18841971/hide-console-window-while-runn… >> >> I've recently "fixed" my own script in Visualworks so as to use these low >> level API (already procided by VW) >> >> BOOL CreateProcessW( >> LPCWSTR imageName, >> LPCWSTR commandLine, >> struct SECURITY_ATTRIBUTES *pSecurity, >> struct SECURITY_ATTRIBUTES *tSecurity, >> BOOL inheritHandles, >> DWORD creationFlags, >> LPVOID environment, >> LPWSTR currentDirectoryName, >> struct STARTUPINFO *startupInfo, >> struct PROCESS_INFORMATION *processInfo) >> >> First argument is fullpath to cmd.exe (take it from environment variable >> 'ComSpec') >> Second argument is '/u /c ' , 'your command here encoded in utf16' >> Security arguments are nil and nil >> inheritHandles is true >> creationFlags is zero >> environment is nil >> currentDirectoryName is nil >> >> startupInfo is more involved: it must be used to pass the pair of pipes >> (handles) for input/output: >> struct STARTUPINFO { >> DWORD cb; >> LPTSTR lpReserved; >> LPTSTR lpDesktop; >> LPTSTR lpTitle; >> DWORD dwX; >> DWORD dwY; >> DWORD dwXSize; >> DWORD dwYSize; >> DWORD dwXCountChars; >> DWORD dwYCountChars; >> DWORD dwFillAttribute; >> DWORD dwFlags; >> WORD wShowWindow; >> WORD cbReserved2; >> LPBYTE lpReserved2; >> HANDLE hStdInput; >> HANDLE hStdOutput; >> HANDLE hStdError; >> } >> >> You initialize it with void GetStartupInfoW(LPSTARTUPINFO lpStartupInfo) >> IMPORTANT: set wShowWindow to 0, >> and then pass the input/output/error handles in last three fields. >> >> processInfo will contain information on output and must be allocated >> struct PROCESS_INFORMATION { >> HANDLE hProcess; >> HANDLE hThread; >> DWORD dwProcessId; >> DWORD dwThreadId; >> } >> >> you can then get exit status thru BOOL GetExitCodeProcess call, close the >> pipes, etc... >> >> >> Le mar. 11 dÃ©c. 2018 Ã 10:08, Christopher Fuhrman < >> christopher.fuhrman(a)inria.fr> a Ã©crit : >> >>> Thanks Peter. That looks like a cool package. I guess I will live with >>> it for now, because I don't want to code too much of a platform-specific >>> solution (yet). >>> >>> On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> This is normal (and much lamented) behavior of cmd. There's >>>> https://github.com/astares/Pharo-OS-Windows which implements parts of >>>> the WinAPI... with which one can create headless windows. (I think it >>>> should be also available in the catalog). >>>> >>>> Peter >>>> >>>> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >>>> christopher.fuhrman(a)inria.fr> wrote: >>>> >>>>> Hello, >>>>> >>>>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance system: >>>>> 'some commands'" which has an annoying side effect of popping up a window >>>>> (which steals the GUI focus in Windows 10). Maybe it's the same on MacOS >>>>> and Linux? >>>>> >>>>> As such, I can't use my Windows PC to do anything else when the mining >>>>> process is running (it can take several minutes). I'm not able to use >>>>> Pharo's OSProcess or OSSubprocess because they don't support Windows (yet?). >>>>> >>>>> I tried creating a separate Windows Desktop (feature of Windows 10), >>>>> but the CMD.EXE window manages to pop up there, too - almost seems like a >>>>> windows bug. >>>>> >>>>> Does anyone know of a way to have the LibC window not pop up? >>>>> >>>>> Cheers, >>>>> >>>>> Christopher >>>>> >>>>

Dec. 11, 2018

Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

by Reg Krock

Hi, I am working on making changes to FileSystemGs to make it work in Gemstone. Who is or the the persons to talk to about changes on the Pharo side. Areas of exploration to date have been: Replacement of File with GsFile - in Gemstone we want to use the native file class. Introduction of a FileMode class hierarchy to replace the passing of they symbols #read and #write. Added the proof of concept of FileMode with subclasses to be passed instead of #write and #read. The classes which have been introduced are: FileMode FileAppendMode FileAppendAndReadMode FileAppendAndReadBinaryMode FileAppendBinaryMode FileReadMode FileReadBinaryMode FileReadWriteMode FileReadWriteMode FileReadWriteBinaryMode FileReadWriteTruncatedMode FileReadWriteTruncatedBinaryMode FileWriteMode FileWriteBinaryMode These classes return the appropriate mode string, (ex: âw+â) and know if the file is writable.Example of change - the text in blue shows the change. Exiting format: (filesystem open: aFileReference path writable: #write) Proposed format: (filesystem open: aFileReference path writable: self store readWriteTruncatedMode) The #readWriteTruncatedMode method would return an instance of FileReadWriteTruncatedMode If a form of this proposal were to be adopted, then the appropriate methods should be renamed to have mode. As an example, #open:writeable: would become #open:mode: Thanks for your help. Reg

Dec. 11, 2018

[Pharo 7.0] Build #26: 22741 Cleanups for SystemVersionTest (lint)

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #26 was: FAILURE. The Pull Request #2050 was integrated: "22741 Cleanups for SystemVersionTest (lint)" Pull request url: https://github.com/pharo-project/pharo/pull/2050 Issue Url: https://pharo.fogbugz.com/f/cases/22741 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 11, 2018

Re: [Pharo-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Nicolas Cellier

I've checked: it's a one liner to be changed in https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win3… near line 826 Since this is generated code from VMMaker, the code has to be changed in slang. IMO, there should be a boolean argument (optional) telling if we want to open the console or not. IMO false by default would be a good thing, though true for backward compatibility is also a possible alternative... Le mar. 11 dÃ©c. 2018 Ã 12:56, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > It is possible, ask stack overflow > > https://stackoverflow.com/questions/4743559/how-to-execute-child-console-pr… > > https://stackoverflow.com/questions/18841971/hide-console-window-while-runn… > > I've recently "fixed" my own script in Visualworks so as to use these low > level API (already procided by VW) > > BOOL CreateProcessW( > LPCWSTR imageName, > LPCWSTR commandLine, > struct SECURITY_ATTRIBUTES *pSecurity, > struct SECURITY_ATTRIBUTES *tSecurity, > BOOL inheritHandles, > DWORD creationFlags, > LPVOID environment, > LPWSTR currentDirectoryName, > struct STARTUPINFO *startupInfo, > struct PROCESS_INFORMATION *processInfo) > > First argument is fullpath to cmd.exe (take it from environment variable > 'ComSpec') > Second argument is '/u /c ' , 'your command here encoded in utf16' > Security arguments are nil and nil > inheritHandles is true > creationFlags is zero > environment is nil > currentDirectoryName is nil > > startupInfo is more involved: it must be used to pass the pair of pipes > (handles) for input/output: > struct STARTUPINFO { > DWORD cb; > LPTSTR lpReserved; > LPTSTR lpDesktop; > LPTSTR lpTitle; > DWORD dwX; > DWORD dwY; > DWORD dwXSize; > DWORD dwYSize; > DWORD dwXCountChars; > DWORD dwYCountChars; > DWORD dwFillAttribute; > DWORD dwFlags; > WORD wShowWindow; > WORD cbReserved2; > LPBYTE lpReserved2; > HANDLE hStdInput; > HANDLE hStdOutput; > HANDLE hStdError; > } > > You initialize it with void GetStartupInfoW(LPSTARTUPINFO lpStartupInfo) > IMPORTANT: set wShowWindow to 0, > and then pass the input/output/error handles in last three fields. > > processInfo will contain information on output and must be allocated > struct PROCESS_INFORMATION { > HANDLE hProcess; > HANDLE hThread; > DWORD dwProcessId; > DWORD dwThreadId; > } > > you can then get exit status thru BOOL GetExitCodeProcess call, close the > pipes, etc... > > > Le mar. 11 dÃ©c. 2018 Ã 10:08, Christopher Fuhrman < > christopher.fuhrman(a)inria.fr> a Ã©crit : > >> Thanks Peter. That looks like a cool package. I guess I will live with it >> for now, because I don't want to code too much of a platform-specific >> solution (yet). >> >> On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> This is normal (and much lamented) behavior of cmd. There's >>> https://github.com/astares/Pharo-OS-Windows which implements parts of >>> the WinAPI... with which one can create headless windows. (I think it >>> should be also available in the catalog). >>> >>> Peter >>> >>> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >>> christopher.fuhrman(a)inria.fr> wrote: >>> >>>> Hello, >>>> >>>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance system: >>>> 'some commands'" which has an annoying side effect of popping up a window >>>> (which steals the GUI focus in Windows 10). Maybe it's the same on MacOS >>>> and Linux? >>>> >>>> As such, I can't use my Windows PC to do anything else when the mining >>>> process is running (it can take several minutes). I'm not able to use >>>> Pharo's OSProcess or OSSubprocess because they don't support Windows (yet?). >>>> >>>> I tried creating a separate Windows Desktop (feature of Windows 10), >>>> but the CMD.EXE window manages to pop up there, too - almost seems like a >>>> windows bug. >>>> >>>> Does anyone know of a way to have the LibC window not pop up? >>>> >>>> Cheers, >>>> >>>> Christopher >>>> >>>

Dec. 11, 2018

[ANN] Pharo Newsletter December 2018

by Marcus Denker

Hi, Last we the Pharo Newsletter December 2018 was send. You can find the archived version now here: https://mailchi.mp/pharo/pharo-newsletter-december-2018 Marcus

Dec. 11, 2018

Re: [Pharo-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Nicolas Cellier

It is possible, ask stack overflow https://stackoverflow.com/questions/4743559/how-to-execute-child-console-pr… https://stackoverflow.com/questions/18841971/hide-console-window-while-runn… I've recently "fixed" my own script in Visualworks so as to use these low level API (already procided by VW) BOOL CreateProcessW( LPCWSTR imageName, LPCWSTR commandLine, struct SECURITY_ATTRIBUTES *pSecurity, struct SECURITY_ATTRIBUTES *tSecurity, BOOL inheritHandles, DWORD creationFlags, LPVOID environment, LPWSTR currentDirectoryName, struct STARTUPINFO *startupInfo, struct PROCESS_INFORMATION *processInfo) First argument is fullpath to cmd.exe (take it from environment variable 'ComSpec') Second argument is '/u /c ' , 'your command here encoded in utf16' Security arguments are nil and nil inheritHandles is true creationFlags is zero environment is nil currentDirectoryName is nil startupInfo is more involved: it must be used to pass the pair of pipes (handles) for input/output: struct STARTUPINFO { DWORD cb; LPTSTR lpReserved; LPTSTR lpDesktop; LPTSTR lpTitle; DWORD dwX; DWORD dwY; DWORD dwXSize; DWORD dwYSize; DWORD dwXCountChars; DWORD dwYCountChars; DWORD dwFillAttribute; DWORD dwFlags; WORD wShowWindow; WORD cbReserved2; LPBYTE lpReserved2; HANDLE hStdInput; HANDLE hStdOutput; HANDLE hStdError; } You initialize it with void GetStartupInfoW(LPSTARTUPINFO lpStartupInfo) IMPORTANT: set wShowWindow to 0, and then pass the input/output/error handles in last three fields. processInfo will contain information on output and must be allocated struct PROCESS_INFORMATION { HANDLE hProcess; HANDLE hThread; DWORD dwProcessId; DWORD dwThreadId; } you can then get exit status thru BOOL GetExitCodeProcess call, close the pipes, etc... Le mar. 11 dÃ©c. 2018 Ã 10:08, Christopher Fuhrman < christopher.fuhrman(a)inria.fr> a Ã©crit : > Thanks Peter. That looks like a cool package. I guess I will live with it > for now, because I don't want to code too much of a platform-specific > solution (yet). > > On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> This is normal (and much lamented) behavior of cmd. There's >> https://github.com/astares/Pharo-OS-Windows which implements parts of >> the WinAPI... with which one can create headless windows. (I think it >> should be also available in the catalog). >> >> Peter >> >> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >> christopher.fuhrman(a)inria.fr> wrote: >> >>> Hello, >>> >>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance system: >>> 'some commands'" which has an annoying side effect of popping up a window >>> (which steals the GUI focus in Windows 10). Maybe it's the same on MacOS >>> and Linux? >>> >>> As such, I can't use my Windows PC to do anything else when the mining >>> process is running (it can take several minutes). I'm not able to use >>> Pharo's OSProcess or OSSubprocess because they don't support Windows (yet?). >>> >>> I tried creating a separate Windows Desktop (feature of Windows 10), but >>> the CMD.EXE window manages to pop up there, too - almost seems like a >>> windows bug. >>> >>> Does anyone know of a way to have the LibC window not pop up? >>> >>> Cheers, >>> >>> Christopher >>> >>

Dec. 11, 2018

Re: [Pharo-dev] Tonel>>sourceDir

by Alistair Grant

Hi Ben, On Tue, 11 Dec 2018 at 12:32, Ben Coman <btc(a)openinworld.com> wrote: > > Now the next question to the list, how would I determine which version of Tonel (e.g. v1.0.9 or v1.0.11 or commit hash) > is loaded in an Image? - Open the Monticello Browser - Find MonticelloTonel-Core - Look at the repositories, in my (slightly older) Pharo 7 image it is: github://pharo-vcs/tonel:v1.0.9 Cheers, Alistair

Dec. 11, 2018

Re: [Pharo-dev] Tonel>>sourceDir

by Ben Coman

On Tue, 11 Dec 2018 at 16:30, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Ben, > > On Sun, 9 Dec 2018 at 16:06, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > For Exercism we are using Tonel in Pharo 6.1. > > We are getting an error "Instance of TonelWriter did not understand > #sourceDir:" > > but the same code works fine on Pharo 7. > > > > The 6.1 image had been updated to latest Iceberg per > https://github.com/pharo-vcs/iceberg#for-pharo-61, so I used ICeberg to > updated to latest "master" of pharo-vcs/tonel but no avail. > > > > In Pharo 7 I see TonelWriter>>sourceDir in protocol "accessing" > > but if I search for "sourceDir" in the pharo-vcs/tonel repo it doesn't > find it... > > > https://github.com/pharo-vcs/tonel/search?q=sourcedir&unscoped_q=sourcedir > > > > I'm having trouble understanding where the #sourceDir method comes from > in Pharo 7. > > Which repo/branch can I load that from into another system? > > It seems like v1.0.9 has it and master doesn't, see: > > > https://github.com/pharo-vcs/tonel/tree/v1.0.9/MonticelloTonel-Core.package… > > (based on just hunting around my Pharo 7 image, I don't really > understand the code :-)) > Great work finding that. Thanks Alistair. Now the next question to the list, how would I determine which version of Tonel (e.g. v1.0.9 or v1.0.11 or commit hash) is loaded in an Image? cheers -ben

Dec. 11, 2018