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

Re: [Pharo-dev] Multiline method definition in Tonel

by Guillermo Polito

Usually Esteban was picky to be able to export and import methods maintaining the original indentation and formatting ^^. On Mon, Dec 10, 2018 at 9:03 PM Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Dec 9, 2018 at 6:28 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> That's just whitespace... or more specifically any of these are fine >> (TonelParser>>extractSelector:) >> >> ``` >> separators := { >> Character space. >> Character tab. >> Character lf. >> Character newPage. >> Character cr. >> $: "not me though"}. >> ``` >> >> You can also try to parse it directly and see the result: >> >> ``` >> def := 'Class { >> #name : #Whatever, >> #superclass : #Object, >> #category : ''Wherever'' >> } >> >> { #category : #protocol } >> Whatever >> testWith: arg1 >> with: arg2 >> with: arg3 [ >> ^ 42 >> ] >> '. >> TonelParser parseStream: def readStream. >> ``` >> >> > Thanks Peter! I was afraid that TonelParser would break if tried to parse > multiline method declarations. > > >> Note that exporting it will result in a "normalized" format, so if you >> keep it in git you will see a change (this also applies to the ordering of >> methods and some optional stuff) >> > > > OK. Thanks for letting me know. And for "normalized" you mean a classical > oneliner right? > > Thanks! > > >> >> Peter >> >> On Fri, Dec 7, 2018 at 5:57 PM Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> I was reading the Tonel spec here [1] but it is not clear to me the case >>> of the multiline method definitions. Are those allowed or not? Say I have >>> a method like this: >>> >>> testWith: arg1 >>> with: arg2 >>> with: arg3 >>> >>> ^ 42 >>> >>> Is that valid as Tonel format? Or tonel expects to have method >>> definition in a one liner like: >>> >>> testWith: arg1 with: arg2 with: arg3 >>> >>> ^ 42 >>> >>> >>> Thanks in advance, >>> >>> >>> [1] https://github.com/pharo-vcs/tonel >>> >>> -- >>> Mariano >>> https://twitter.com/MartinezPeck >>> http://marianopeck.wordpress.com >>> >> > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Dec. 12, 2018

Re: [Pharo-dev] Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

by Sven Van Caekenberghe

> On 12 Dec 2018, at 13:21, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Reg, > > Thanks for your email, improving FileSystem is a cool thing ^^. > > On Tue, Dec 11, 2018 at 8:39 PM Reg Krock via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > 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. > > Well, I don't know if there is a single maintainer. I think that myself, Alistair, Sven, and many others can answer to questions on different aspects of file system. > Anyways, I'd suggest you just send your emails to this mailing list, the person concerned/interested will answer when possible ;) > > > Areas of exploration to date have been: > â¢ Replacement of File with GsFile - in Gemstone we want to use the native file class. > How have you made it pluggable? This maybe requires the introduction of a backend or a separate store "GSFileSystemStore"? > Does Gemstone require different kind of implementations for different platforms like linux/windows/osx or just a unix-like one is enough? > > â¢ 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 > > I like the introduction of objects :) me too > What is the difference between the binary and non binary modes? > How do you specify encoding for non binary ones? Or you assume ascii? > Also, the fact that the "binary" aspect is repeated all over the hierarchy makes me think they could be composable aspects of a file mode. indeed. another remark: we are trying to move away (and mostly have) from streams that are both readable and writeable at the same time - this is hardly ever needed and complicates things a lot (socket/network streams being a bit of an exception, although the reading and writing are independent there). > > â¢ 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) > > Well, AFAIU, this is not public API (and it uses booleans to indicate "mode"). > Usually end users would simply do: > > aFileReference writeStream. > aFileReference binaryWriteStream. > aFileReference readStream. > aFileReference binaryReadStream. > > But yes, I like also to model modes such as truncated, append, "force new". > > > 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: > > Well, we could keep the old API and build a higher level one on top, don't we? > > Do you have your code in a repository we could check? > > > Thanks for your help. > > Thanks to you! > Guille > > Reg

Dec. 12, 2018

Re: [Pharo-dev] Pharo FIleSystem Compatibility with Gemstone's FileSystemGs

by Guillermo Polito

Hi Reg, Thanks for your email, improving FileSystem is a cool thing ^^. On Tue, Dec 11, 2018 at 8:39 PM Reg Krock via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > 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. > Well, I don't know if there is a single maintainer. I think that myself, Alistair, Sven, and many others can answer to questions on different aspects of file system. Anyways, I'd suggest you just send your emails to this mailing list, the person concerned/interested will answer when possible ;) > > Areas of exploration to date have been: > > 1. Replacement of File with GsFile - in Gemstone we want to use the > native file class. > > How have you made it pluggable? This maybe requires the introduction of a backend or a separate store "GSFileSystemStore"? Does Gemstone require different kind of implementations for different platforms like linux/windows/osx or just a unix-like one is enough? > > 1. 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 > I like the introduction of objects :) What is the difference between the binary and non binary modes? How do you specify encoding for non binary ones? Or you assume ascii? Also, the fact that the "binary" aspect is repeated all over the hierarchy makes me think they could be composable aspects of a file mode. > > - 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) > Well, AFAIU, this is not public API (and it uses booleans to indicate "mode"). Usually end users would simply do: aFileReference writeStream. aFileReference binaryWriteStream. aFileReference readStream. aFileReference binaryReadStream. But yes, I like also to model modes such as truncated, append, "force new". > 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: > Well, we could keep the old API and build a higher level one on top, don't we? Do you have your code in a repository we could check? > Thanks for your help. > Thanks to you! Guille > Reg >

Dec. 12, 2018

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

by Guillermo Polito

Hi all, I think that Christopher and Peter are talking about ProcessWrapper and not OSProcess, which is fetched from here: http://leves.web.elte.hu/ProcessWrapper/ I think this was originally Levente's work? The source code is stored in a zip next to the dll in the same server, no history attached to it. Guille On Wed, Dec 12, 2018 at 12:30 AM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Nicolas, > > On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> 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 >> > > So what changes do you want exactly? I'm happy to do the Smalltalk/Slang > writing (adding the parameter, etc) but I don't know what result you'd like > to see. Can you post the body of the function as you'd like to see it or > the lines around 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 >>>>>> >>>>> > _,,,^..^,,,_ > best, Eliot > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Dec. 12, 2018

[ANN] Next Pharo Sprint: Dec 21

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Dec 21, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973628

Dec. 12, 2018

[Pharo 7.0] Build #29: 22751-Improve-RFLiteralVariableNode-printing

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

There is a new Pharo build available! The status of the build #29 was: FAILURE. The Pull Request #2058 was integrated: "22751-Improve-RFLiteralVariableNode-printing" Pull request url: https://github.com/pharo-project/pharo/pull/2058 Issue Url: https://pharo.fogbugz.com/f/cases/22751 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

[Pharo 7.0] Build #28: 22703-Block-execution-arguments-reification

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

There is a new Pharo build available! The status of the build #28 was: SUCCESS. The Pull Request #2059 was integrated: "22703-Block-execution-arguments-reification" Pull request url: https://github.com/pharo-project/pharo/pull/2059 Issue Url: https://pharo.fogbugz.com/f/cases/22703 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

Re: [Pharo-dev] [ANN] Pharo Newsletter December 2018

by Marcus Denker

> On 11 Dec 2018, at 14:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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 > I am looking for content for the January newsletter. e.g. if you know a library that has not yet been listed, or just one where some new version has been released. Or people could write âlargerâ articles (a paragraph or two) about their favourite things. Or maybe there are videos that would be nice to be added to the newsletter? Marcus

Dec. 12, 2018

[Pharo 7.0] Build #27: 22736-Clean-PharoWelcomePage

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

There is a new Pharo build available! The status of the build #27 was: SUCCESS. The Pull Request #2047 was integrated: "22736-Clean-PharoWelcomePage" Pull request url: https://github.com/pharo-project/pharo/pull/2047 Issue Url: https://pharo.fogbugz.com/f/cases/22736 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

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

by Eliot Miranda

Hi Nicolas, On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 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 > So what changes do you want exactly? I'm happy to do the Smalltalk/Slang writing (adding the parameter, etc) but I don't know what result you'd like to see. Can you post the body of the function as you'd like to see it or the lines around 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 >>>>> >>>> _,,,^..^,,,_ best, Eliot

Dec. 11, 2018