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

[Pharo 7.0] Build #33: 22755-Reflectivity-cleanups-tests-unify-variable-Naming

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

There is a new Pharo build available! The status of the build #33 was: SUCCESS. The Pull Request #2063 was integrated: "22755-Reflectivity-cleanups-tests-unify-variable-Naming" Pull request url: https://github.com/pharo-project/pharo/pull/2063 Issue Url: https://pharo.fogbugz.com/f/cases/22755 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

[Pharo 7.0] Build #32: 22750-Add-GTPlayground-classopenUrl

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

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

Dec. 12, 2018

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

by Esteban Lorenzano

Yes, it should preserve the format. If not, there is bug :) Esteban > On 12 Dec 2018, at 15:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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 <mailto:marianopeck@gmail.com>> wrote: > > > On Sun, Dec 9, 2018 at 6:28 PM Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@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 <mailto:marianopeck@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 <https://github.com/pharo-vcs/tonel> > > -- > Mariano > https://twitter.com/MartinezPeck <https://twitter.com/MartinezPeck> > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > -- > Mariano > https://twitter.com/MartinezPeck <https://twitter.com/MartinezPeck> > http://marianopeck.wordpress.com <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] Fixed by reboot

by phil＠highoctane.be

Logging out and back in also solves the issue for me. I guess that a dll handle is not released properly. Phil On Wed, Dec 12, 2018, 16:14 Guillermo Polito <guillermopolito(a)gmail.com wrote: > > > On Sun, Dec 9, 2018 at 2:26 AM Ben Coman <btc(a)openinworld.com> wrote: > >> Just reporting a strange occurrence in case anyone sees the same. >> >> I was using PharoLauncher fine, then it wasn't. >> When trying to launch an image it started reporting with "ProcessWrapper >> newProcess failed..." >> > > Has your Pharo launcher been open for many time/hours/days? > > >> >> First time I've ever seen that, and fixed by a reboot, but still strange. >> There are a couple of other troubles that get fixed by reboot. >> Anyone have insight into an underlying cause? >> > > I've started using windows two days a week to spot more issues and be more > efficiente to fix them... > And I've seen many issues regarding DLL opening/loading both by VM plugins > and FFI calls. >

Dec. 12, 2018

[Pharo 7.0] Build #31: 22752-cleanup-preamble-generation--test-for-method-Sequence

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

There is a new Pharo build available! The status of the build #31 was: FAILURE. The Pull Request #2060 was integrated: "22752-cleanup-preamble-generation--test-for-method-Sequence" Pull request url: https://github.com/pharo-project/pharo/pull/2060 Issue Url: https://pharo.fogbugz.com/f/cases/22752 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

Re: [Pharo-dev] Fixed by reboot

by Ben Coman

On Wed, 12 Dec 2018 at 23:14, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Sun, Dec 9, 2018 at 2:26 AM Ben Coman <btc(a)openinworld.com> wrote: > >> Just reporting a strange occurrence in case anyone sees the same. >> >> I was using PharoLauncher fine, then it wasn't. >> When trying to launch an image it started reporting with "ProcessWrapper >> newProcess failed..." >> > > Has your Pharo launcher been open for many time/hours/days? > Yes, many days. Including across laptop going to sleep morning and evening travelling between home and office. I like it not-quitting on launch. cheers -ben

Dec. 12, 2018

[ANN] Git Thermite integration with Iceberg

by Ronie Salgado

Hello, Some time ago I presented Git Thermite in this mailing. Git Thermite is a tool for visualizing Git commits that I am making for my master thesis. Now I have managed to integrate Git Thermite with Iceberg. GitHub page: https://github.com/ronsaldo/pharo-git-thermite Demo video: https://www.youtube.com/watch?v=TdBHpdyFgZE Visualization learning material: https://github.com/ronsaldo/pharo-git-thermite/blob/master/doc/learning-mat… Feedback: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… Pharo 7 installation doIt: Metacello new baseline: 'Thermite'; repository: 'github://ronsaldo/pharo-git-thermite/src'; load Please, I would love to get some usage feedback through the Google form :-) Best regards, Ronie

Dec. 12, 2018

Re: [Pharo-dev] Fixed by reboot

by Guillermo Polito

On Sun, Dec 9, 2018 at 2:26 AM Ben Coman <btc(a)openinworld.com> wrote: > Just reporting a strange occurrence in case anyone sees the same. > > I was using PharoLauncher fine, then it wasn't. > When trying to launch an image it started reporting with "ProcessWrapper > newProcess failed..." > Has your Pharo launcher been open for many time/hours/days? > > First time I've ever seen that, and fixed by a reboot, but still strange. > There are a couple of other troubles that get fixed by reboot. > Anyone have insight into an underlying cause? > I've started using windows two days a week to spot more issues and be more efficiente to fix them... And I've seen many issues regarding DLL opening/loading both by VM plugins and FFI calls.

Dec. 12, 2018

Re: [Pharo-dev] OSSubprocess equivalent in Pharo7?

by Guillermo Polito

Hi Hans, On Thu, Dec 6, 2018 at 12:14 AM Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > Hello, > I noticed that theOSSubprocess functionality for communicating with OS > subprocesses depends on OSSAttachableFileStream which is a subclass of > deprecated FileStream OSSubprocess works in Pharo7. Yes, we should find a replacement/solution for the deprecation of FileStream, but it's not deprecated because it does not work anymore but because the new version is cleaner, clearer and more flexible. So all existing code should continue working. > (incidentally, the project is not marked as being > compatible with Pharo7). > Are you talking about the catalog? Well, since Pharo7 is not officially released OSSubprocess has not been marked yet, that's all. > The popen()/fgetc() based examples in UNIXProcess are blocking, which is > unusable for any but the most basic external command executions. > Are there plans to implement a proper replacement in Pharo7? > Can you check if OSSubproces tests are running green for you? Are there tests cases for cases similar to popen/fgetc? I'm interested in knowing what are exactly the problems you've found. Thanks, Guille > Cheers, > Hans-Martin > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- 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

[Pharo 7.0] Build #30: 22742 Package ManifestHiedra should be tagged

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

There is a new Pharo build available! The status of the build #30 was: SUCCESS. The Pull Request #2051 was integrated: "22742 Package ManifestHiedra should be tagged" Pull request url: https://github.com/pharo-project/pharo/pull/2051 Issue Url: https://pharo.fogbugz.com/f/cases/22742 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018

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

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

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

by Christopher Fuhrman

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 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 :-)) HTH, Alistair

Dec. 11, 2018

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

by Sven Van Caekenberghe

https://github.com/pharo-project/pharo/pull/2057 https://pharo.fogbugz.com/f/cases/22750/Add-GTPlayground-class-openUrl Note that this is actually more universal than the specific website/webservice we are currently using. It works for any web resource that is returning text/plain documents. For example, try GTPlayground openUrl: 'http://zn.stfx.eu/zn/numbers.txt'. (Apart from the fact that that server is currently down ;-) > 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. 10, 2018

stfx.eu down

by Sven Van Caekenberghe

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. 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. 10, 2018

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

by Peter Uhnak

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. 10, 2018

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

by Mariano Martinez Peck

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

Dec. 10, 2018

[Pharo 7.0] Build #25: 22735-ZipArchive-classisZipArchive-is-broken-in-P7

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

There is a new Pharo build available! The status of the build #25 was: SUCCESS. The Pull Request #2046 was integrated: "22735-ZipArchive-classisZipArchive-is-broken-in-P7" Pull request url: https://github.com/pharo-project/pharo/pull/2046 Issue Url: https://pharo.fogbugz.com/f/cases/22735 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 10, 2018

Re: halos

by John Kimber

shift-control click works for me on 1384. HTH, john -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 10, 2018

Re: [Pharo-dev] Fwd: Tonel sourceDir

by Torsten Bergmann

Hi Ben, in Pharo 7 Iceberg works different - the source dir is part of the metadata in the repo (right click on a repo and say "Repair" so it offers you to add metadata). So for instance https://github.com/astares/Pharo-OS-Windows is already converted to the "latest and greates" and has a .project file with { 'srcDirectory' : 'src' } So you just can load it without giving the source dir explicitly. Also note that the src file directory has .properties file depicting the format: { #format : #tonel } Tonel is now recommended. Hope that helps a little bit. Thanks T.

Dec. 10, 2018

Re: [Pharo-dev] Fwd: Tonel sourceDir

by Guillermo Polito

Hi Ben, I'm going to check emails on wednesday. I'm about to be on planes for 16~20 hours :) Le lun. 10 dÃ©c. 2018 Ã 08:29, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > Okay, that was 13 hours ago. Once again... > (CCing Esteban & Guille. Can you guys let me know if its at least getting > out) > > ---------- Forwarded message --------- > From: Ben Coman <btc(a)openinworld.com> > Date: Mon, 10 Dec 2018 at 06:18 > Subject: Tonel sourceDir > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > This did make it through the mail list in 8 hours, so mabe the double > arrow in the subject line confused things. > > Trying again... > > ---------- Forwarded message --------- > From: Ben Coman <btc(a)openinworld.com> > Date: Sun, 9 Dec 2018 at 23:05 > Subject: Tonel>>sourceDir > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > > 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? > > cheers -ben > -- 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. 10, 2018

Fwd: Tonel sourceDir

by Ben Coman

Okay, that was 13 hours ago. Once again... (CCing Esteban & Guille. Can you guys let me know if its at least getting out) ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Mon, 10 Dec 2018 at 06:18 Subject: Tonel sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> This did make it through the mail list in 8 hours, so mabe the double arrow in the subject line confused things. Trying again... ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Sun, 9 Dec 2018 at 23:05 Subject: Tonel>>sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> 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? cheers -ben

Dec. 10, 2018

LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Christopher Fuhrman

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. 10, 2018

Re: [Pharo-dev] periodic auto actions on bug tracker

by Marcus Denker

> On 9 Dec 2018, at 01:50, Ben Coman <btc(a)openinworld.com> wrote: > > I support the auto-closing of old tickets to avoid bug bankruptcy. Sometimes things seem more important at the time and when my own tickets come back around I get to be more analytical about the effort/reward balance. > > It would be useful to expand this a bit to have a quarterly mail out saying something like "Is this issue still important to you? Try socializing it on the pharo-dev mail list. Issues going twelve months without interaction will be auto-closed". Then its not a bad surprise to new users when their ticket is auto-closed. > Yes, that is a good idea. I will add it to the things to do for the issue tracker / integration related scripts. Marcus

Dec. 10, 2018

Esteban's ChangeLog week of 3 December 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 3 December 2018 to 9 December 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=3/12/2018&to=9/12/2018 ChangeLog ========= 6 December 2018: ---------------- * I made a small [PR](https://github.com/pharo-ide/Calypso/pull/375) on Calypso to better expose the contextual spotter that helps to find available Calypso commands. 5 December 2018: ---------------- * Ok, finally I finished next stop on automation of releases, which made us to change the default development branch (to "Pharo7.0" for the moment). This will allow us to keep different active "development" branches. One thing I would like to achieve eventually is to keep: * A current development version (it will be Pharo8.0 soon). * A maintained stable version (Pharo7.0 and potential Pharo7.1, etc.). * A Long term support (LTS) version that will continue incorporating critic systems. So well, this are the steps to arrive there :) cheers! Esteban

Dec. 10, 2018

Tonel sourceDir

by Ben Coman

This did make it through the mail list in 8 hours, so mabe the double arrow in the subject line confused things. Trying again... ---------- Forwarded message --------- From: Ben Coman <btc(a)openinworld.com> Date: Sun, 9 Dec 2018 at 23:05 Subject: Tonel>>sourceDir To: Pharo Development List <pharo-dev(a)lists.pharo.org> 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? cheers -ben

Dec. 9, 2018

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

by Peter Uhnak

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. ``` 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) 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 >

Dec. 9, 2018

Tonel>>sourceDir

by Ben Coman

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? cheers -ben

Dec. 9, 2018

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

by Ben Coman

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. 9, 2018

Re: [Pharo-dev] Calypso equivalent <nautilusGlobalPackageMenu>

by Denis Kudriashov

Hi Ben. All Calypso commands are implemented with Commander. Look for example at remove package command. The menu item is declared by SycRemovePackageCommand class>>#fullBrowserMenuActivation. Doc for Commander https://github.com/SquareBracketAssociates/Booklet-Infrastructure (with link to pdf). Ð²Ñ, 9 Ð´ÐµÐº. 2018 Ð³. Ð² 01:50, Ben Coman <btc(a)openinworld.com>: > What is the Calypso equivalent of <nautilusGlobalPackageMenu> ? > I need to add an extra menu item to the Packages context menu. > > cheers -ben >

Dec. 9, 2018

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

by Sven Van Caekenberghe

> 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" 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.

Dec. 9, 2018

Re: [Pharo-dev] periodic auto actions on bug tracker

by Tim Mackinnon

Itâs a great idea - I too have a good look at what I previously reported and decide if itâs still relevant and whether it makes sense to still pursue it. Sent from my iPhone > On 9 Dec 2018, at 06:20, Ben Coman <btc(a)openinworld.com> wrote: > > I support the auto-closing of old tickets to avoid bug bankruptcy. Sometimes things seem more important at the time and when my own tickets come back around I get to be more analytical about the effort/reward balance. > > It would be useful to expand this a bit to have a quarterly mail out saying something like "Is this issue still important to you? Try socializing it on the pharo-dev mail list. Issues going twelve months without interaction will be auto-closed". Then its not a bad surprise to new users when their ticket is auto-closed. > > cheers -ben > >

Dec. 9, 2018

Calypso equivalent <nautilusGlobalPackageMenu>

by Ben Coman

What is the Calypso equivalent of <nautilusGlobalPackageMenu> ? I need to add an extra menu item to the Packages context menu. cheers -ben

Dec. 9, 2018

Fixed by reboot

by Ben Coman

Just reporting a strange occurrence in case anyone sees the same. I was using PharoLauncher fine, then it wasn't. When trying to launch an image it started reporting with "ProcessWrapper newProcess failed..." First time I've ever seen that, and fixed by a reboot, but still strange. There are a couple of other troubles that get fixed by reboot. Anyone have insight into an underlying cause? cheers -ben

Dec. 9, 2018

periodic auto actions on bug tracker

by Ben Coman

I support the auto-closing of old tickets to avoid bug bankruptcy. Sometimes things seem more important at the time and when my own tickets come back around I get to be more analytical about the effort/reward balance. It would be useful to expand this a bit to have a quarterly mail out saying something like "Is this issue still important to you? Try socializing it on the pharo-dev mail list. Issues going twelve months without interaction will be auto-closed". Then its not a bad surprise to new users when their ticket is auto-closed. cheers -ben

Dec. 9, 2018

Re: [Pharo-dev] Release candidate version numbers

by Ben Coman

> > Le sam. 8 dÃ©c. 2018 Ã 13:42, Ben Coman <btc(a)openinworld.com> a Ã©crit : > >> In PharoLauncher >> >> under "Pharo 7 (development version)" opening template >> Pharo7.0.0-rc1.build.1433.sha.8292c1f.arch.32bit >> then System > System Report shows... >> >> Pharo-7.0.0+rc1.build.1433.sha.8292c1f795527f5969a227d22bc32f1c4e93b710 (32 >> Bit) >> >> >> but under "Official distributions" I see >> Pharo 7.0 - 32bit (development version) >> then System > System Report shows... >> >> Pharo-7.0.0+rc1.build.24.sha.41c89eb7dd9f362ca1ba874f1d9a42602396e002 (32 >> Bit) >> >> Why using such a different and small number "24", >> and a long way from 1433 ? >> > > On Sun, 9 Dec 2018 at 02:00, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > i think it may come from the fact that this is a new branch (development got renamed into pharo7.0) Makes sense. Good to know. I understand there may be constraints on that being fixable, and that someone may be in the middle of working on this before any cleanup, but just an other oddity I observed... [image: build-dates.png] cheers -ben

Dec. 9, 2018

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

by Ben Coman

On Sun, 9 Dec 2018 at 00:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, > > > On 8 Dec 2018, at 17:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On discord a user provided some feedback... > > > > when you post anything to ws.stfx.eu - e.g. here: > http://ws.stfx.eu/CJGVYTTQD3RY - the page says that I should use > "ZnWorkspace openUrl: 'http://ws.stfx.eu/CJGVYTTQD3RY'." to retrieve it. > However, there is no class called "ZnWorkspace" in Pharo 6.1 so this should > probably be updated. > > > > "Remote publish" button is located fairly prominently in the top right > corner of Pharo Playground window so Pharo beginners will probably see it > fairly soon after they start experimenting and try clicking on it. The text > should be updated so the instructions actually work. > > > > Also the footer of the page says copyright is 2013, and it would look > better to newcomers if the copyright date was more recent. > > > > ---------- > > cheers -ben > > The 'Shared Smalltalk Workspaces' [http://ws.stfx.eu] service is indeed > old (but has been working unattended for years). Quite impressive that. > It was later hijacked (in a good way) by the Playground. It should indeed > be upgraded a bit, I'll look into it but can't promise anything. > Since its been incorporated as a standard feature, is it time for it to move domain to ws.pharo.org. Maybe the Association/Consortium fund your time to assist with that? Do note that you can paste a SSW URL like http://ws.stfx.eu/CJGVYTTQD3RY > into Spotter to open it in a new Playground. A cool, but hidden feature. So > technically there is no need for more. > Nice, that worked well. cheers -ben > > You can also access a page with the following expression: > > ZnClient new > systemPolicy; > beOneShot; > accept: ZnMimeType textPlain; > url: 'http://ws.stfx.eu/CJGVYTTQD3RY'; > get. > > Maybe an additional menu item somewhere ? > > Sven > > >

Dec. 9, 2018

Re: [Pharo-dev] Release candidate version numbers

by Guillermo Polito

Hi, i think it may come from the fact that this is a new branch (development got renamed into pharo7.0) guille Le sam. 8 dÃ©c. 2018 Ã 13:42, Ben Coman <btc(a)openinworld.com> a Ã©crit : > In PharoLauncher > > under "Pharo 7 (development version)" opening template > Pharo7.0.0-rc1.build.1433.sha.8292c1f.arch.32bit > then System > System Report shows... > > Pharo-7.0.0+rc1.build.1433.sha.8292c1f795527f5969a227d22bc32f1c4e93b710 (32 > Bit) > > > but under "Official distributions" I see > Pharo 7.0 - 32bit (development version) > then System > System Report shows... > > Pharo-7.0.0+rc1.build.24.sha.41c89eb7dd9f362ca1ba874f1d9a42602396e002 (32 > Bit) > > Why using such a different and small number "24", > and a long way from 1433 ? > > cheers -ben > -- 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. 8, 2018

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

by Sven Van Caekenberghe

Ben, > On 8 Dec 2018, at 17:19, Ben Coman <btc(a)openinworld.com> wrote: > > On discord a user provided some feedback... > > when you post anything to ws.stfx.eu - e.g. here: http://ws.stfx.eu/CJGVYTTQD3RY - the page says that I should use "ZnWorkspace openUrl: 'http://ws.stfx.eu/CJGVYTTQD3RY'." to retrieve it. However, there is no class called "ZnWorkspace" in Pharo 6.1 so this should probably be updated. > > "Remote publish" button is located fairly prominently in the top right corner of Pharo Playground window so Pharo beginners will probably see it fairly soon after they start experimenting and try clicking on it. The text should be updated so the instructions actually work. > > Also the footer of the page says copyright is 2013, and it would look better to newcomers if the copyright date was more recent. > > ---------- > cheers -ben The 'Shared Smalltalk Workspaces' [http://ws.stfx.eu] service is indeed old (but has been working unattended for years). It was later hijacked (in a good way) by the Playground. It should indeed be upgraded a bit, I'll look into it but can't promise anything. Do note that you can paste a SSW URL like http://ws.stfx.eu/CJGVYTTQD3RY into Spotter to open it in a new Playground. A cool, but hidden feature. So technically there is no need for more. You can also access a page with the following expression: ZnClient new systemPolicy; beOneShot; accept: ZnMimeType textPlain; url: 'http://ws.stfx.eu/CJGVYTTQD3RY'; get. Maybe an additional menu item somewhere ? Sven

Dec. 8, 2018

Release candidate version numbers

by Ben Coman

In PharoLauncher under "Pharo 7 (development version)" opening template Pharo7.0.0-rc1.build.1433.sha.8292c1f.arch.32bit then System > System Report shows... Pharo-7.0.0+rc1.build.1433.sha.8292c1f795527f5969a227d22bc32f1c4e93b710 (32 Bit) but under "Official distributions" I see Pharo 7.0 - 32bit (development version) then System > System Report shows... Pharo-7.0.0+rc1.build.24.sha.41c89eb7dd9f362ca1ba874f1d9a42602396e002 (32 Bit) Why using such a different and small number "24", and a long way from 1433 ? cheers -ben

Dec. 8, 2018

Playground "remote publish" feedback from discord

by Ben Coman

On discord a user provided some feedback... when you post anything to ws.stfx.eu - e.g. here: http://ws.stfx.eu/CJGVYTTQD3RY - the page says that I should use "ZnWorkspace openUrl: 'http://ws.stfx.eu/CJGVYTTQD3RY'." to retrieve it. However, there is no class called "ZnWorkspace" in Pharo 6.1 so this should probably be updated. "Remote publish" button is located fairly prominently in the top right corner of Pharo Playground window so Pharo beginners will probably see it fairly soon after they start experimenting and try clicking on it. The text should be updated so the instructions actually work. Also the footer of the page says copyright is 2013, and it would look better to newcomers if the copyright date was more recent. ---------- cheers -ben

Dec. 8, 2018

Which version of libfreetype.dll?

by Alistair Grant

Hi Esteban, If I zeroconf Pharo 7 on Windows (in cygwin): $ curl get.pharo.org/70+vmLatest | bash And then move to a dos box: C:\cygwin\tmp\p7>pharo-vm\PharoConsole.exe --headless Pharo.image eval "FT2Library current libraryVersion" 2.6.5 Is this what you expect? Thanks, Alistair

Dec. 7, 2018

Multiline method definition in Tonel

by Mariano Martinez Peck

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

Dec. 7, 2018

[Pharo 7.0] Build #24: 22738-Remove-Window-color-option

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

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

Dec. 7, 2018

[Pharo 7.0] Build #23: 22740 system settings should be system settings core

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

There is a new Pharo build available! The status of the build #23 was: SUCCESS. The Pull Request #2049 was integrated: "22740 system settings should be system settings core" Pull request url: https://github.com/pharo-project/pharo/pull/2049 Issue Url: https://pharo.fogbugz.com/f/cases/22740 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 7, 2018

Re: [Pharo-dev] [Pharo-users] Fwd: Announcing Repl.it Multiplayer

by Erik Stel

Actually I'm working on a hobby project for creating a Web IDE for Smalltalk. The idea is to have people (actually kids) work together in it. Purpose is to have an environment for kids to learn to program with the help of other kids and one or more experienced programmers/mentors/coaches. My current plans are to create a REST or Web API on top of a Smalltalk image which allows querying the image as well as execute code. The Web API should ideally be general enough to support different Smalltalk flavours. (This will require some tweaking though ;-) The actual IDE will be a web application in Pharo which can access other Smalltalk images through the Web API. The Smalltalk image with the IDE itself will likewise be query-able and editable. It should be real Smalltalk in that the IDE can be edited by the 'user'. Web API could look something like (this is just from the top of my head): GET /packages GET /packages/<package-name>/classes GET /packages/<package-name>/classes/<class-name> POST /packages/<package-name>/classes/<class-name>/<method-name> GET /workspaces POST /workspaces/<workspace-id>/doit POST /workspaces/<workspace-id>/inspect Some names will have to be more general since Cuis uses Category instead of Package for example. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 7, 2018

[Pharo 7.0] Build #22: 22745 ManifestHermes and HEBinaryReader should be tagged

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

There is a new Pharo build available! The status of the build #22 was: FAILURE. The Pull Request #2053 was integrated: "22745 ManifestHermes and HEBinaryReader should be tagged" Pull request url: https://github.com/pharo-project/pharo/pull/2053 Issue Url: https://pharo.fogbugz.com/f/cases/22745 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 7, 2018

Re: [Pharo-dev] [Pharo-users] Fwd: Announcing Repl.it Multiplayer

by phil＠highoctane.be

With XMPPTalk, I had the idea to have one server doing the messenging and instead of sharing an image, we could have source code shipped around. DiscordSt is nice but depends on a proprietary service, so have one's own self hosted infrastructure would be nicer. Also, if we associate this to Telepharo, we could have one image doing the messenging in a safe area and a remote image (running on the same machine) doing the evaluations of the code. So that we wouldn't have a lockup in the main UI. End of year holidays may be a good time to try these ideas out. Best, Phil On Fri, Dec 7, 2018 at 7:27 AM Tim Mackinnon <tim(a)testit.works> wrote: > There was also the work that Jason and Julien did with âWolfpackâ (this > was in VisualWorks) that explores the idea of group programming in an > image. They did quite a few workshops on it, and it was tantalisingly > interesting but I think they ran out of steam. > > Tim > > Sent from my iPhone > > On 7 Dec 2018, at 06:34, Ben Coman <btc(a)openinworld.com> wrote: > > One advantage of their seemingly text-based system might be bandwidth, but > Pharo is a graphical system. > It might be worthwhile for dispersed teams working on web hosted Pharo > systems, but we already have remote tools. > I guess it might almost already be able to have multiple people using them > simultaneously on the one image(?), but everyone would be looking at > different Inpectors. > It could be cool for a common Inspector instance to show up on multiple > user screens. > But is it that much better than the other suggestions?? > > cheers -ben > > On Fri, 7 Dec 2018 at 06:03, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Santiago, >> >> On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> Would this be interesting to have in pharo?? >>> >> >> There is already previous relevant work. Look up Kansas for Self >> http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak >> http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like >> UI would be a major regression. Note that we already have lots fo relevant >> infrastructure, such as a VNC server that allows desktops to be shared. >> Building a shared programming environment for Pharo doesn't need to start >> from such limited models as the Multiplayer. >> >> >>> >>> What do you think? >>> >>> ---------- Forwarded message --------- >>> From: Amjad from Repl.it <contact(a)repl.it> >>> Date: jue., 6 de dic. de 2018 21:55 >>> Subject: Announcing Repl.it Multiplayer >>> To: <santiagobragagnolo(a)gmail.com> >>> >>> >>> The official release of Repl.it Multiplayer, the collaborative coding >>> experience. >>> [image: Repl.it Logo] >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> >>> >>> Hey Santiago, >>> >>> Professional programmers all know that software development is a >>> fundamentally social experience. But coding remains a single-player >>> experience by default â today, we're changing this! >>> >>> As part of our mission to make computing more accessible, we believe >>> connecting coders, learners, and teachers together in real time, in the >>> development environment, is a big piece of the puzzle. That's why we're >>> proud to announce *Multiplayer*. >>> >>> Multiplayer lets you code with friends in the same editor, execute >>> programs in the same interpreter, interact with the same terminal, chat in >>> the IDE, edit files and share the same system resources, and ship >>> applications from the same interface! We've redesigned every part of our >>> infrastructure to work in multiplayer mode -- from the filesystem to the >>> interpreter. >>> [image: Repl.it Multiplayer] >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> >>> >>> Read more about it here >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, >>> or, better yet, hop in >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, >>> invite your friends and start coding! >>> >>> Amjad from Repl.it >>> >>> 767 Bryant St, #210, San Francisco, CA 94107 >>> >>> Unsubscribe >>> <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> >>> - Unsubscribe Preferences >>> <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >

Dec. 7, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by phil＠highoctane.be

True, bandwidth is a pain, especially for a FullHD or more screen. I am doing lots of remote work with ssh and tmux/tmux attach. Works wonderfully well. I wish we had a fuse filesystem for Pharo so we could basically edit stuff out of a mounted image with things like vim. With true headless mode, I guess we will have those topics coming to the forefront. Phil On Fri, Dec 7, 2018 at 2:06 AM Ben Coman <btc(a)openinworld.com> wrote: > One advantage of their seemingly text-based system might be bandwidth, but > Pharo is a graphical system. > It might be worthwhile for dispersed teams working on web hosted Pharo > systems, but we already have remote tools. > I guess it might almost already be able to have multiple people using them > simultaneously on the one image(?), but everyone would be looking at > different Inpectors. > It could be cool for a common Inspector instance to show up on multiple > user screens. > But is it that much better than the other suggestions?? > > cheers -ben > > On Fri, 7 Dec 2018 at 06:03, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Santiago, >> >> On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < >> santiagobragagnolo(a)gmail.com> wrote: >> >>> Would this be interesting to have in pharo?? >>> >> >> There is already previous relevant work. Look up Kansas for Self >> http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak >> http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like >> UI would be a major regression. Note that we already have lots fo relevant >> infrastructure, such as a VNC server that allows desktops to be shared. >> Building a shared programming environment for Pharo doesn't need to start >> from such limited models as the Multiplayer. >> >> >>> >>> What do you think? >>> >>> ---------- Forwarded message --------- >>> From: Amjad from Repl.it <contact(a)repl.it> >>> Date: jue., 6 de dic. de 2018 21:55 >>> Subject: Announcing Repl.it Multiplayer >>> To: <santiagobragagnolo(a)gmail.com> >>> >>> >>> The official release of Repl.it Multiplayer, the collaborative coding >>> experience. >>> [image: Repl.it Logo] >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> >>> >>> Hey Santiago, >>> >>> Professional programmers all know that software development is a >>> fundamentally social experience. But coding remains a single-player >>> experience by default â today, we're changing this! >>> >>> As part of our mission to make computing more accessible, we believe >>> connecting coders, learners, and teachers together in real time, in the >>> development environment, is a big piece of the puzzle. That's why we're >>> proud to announce *Multiplayer*. >>> >>> Multiplayer lets you code with friends in the same editor, execute >>> programs in the same interpreter, interact with the same terminal, chat in >>> the IDE, edit files and share the same system resources, and ship >>> applications from the same interface! We've redesigned every part of our >>> infrastructure to work in multiplayer mode -- from the filesystem to the >>> interpreter. >>> [image: Repl.it Multiplayer] >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> >>> >>> Read more about it here >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, >>> or, better yet, hop in >>> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, >>> invite your friends and start coding! >>> >>> Amjad from Repl.it >>> >>> 767 Bryant St, #210, San Francisco, CA 94107 >>> >>> Unsubscribe >>> <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> >>> - Unsubscribe Preferences >>> <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >

Dec. 7, 2018

Re: [Pharo-dev] [Pharo-users] Fwd: Announcing Repl.it Multiplayer

by Tim Mackinnon

There was also the work that Jason and Julien did with âWolfpackâ (this was in VisualWorks) that explores the idea of group programming in an image. They did quite a few workshops on it, and it was tantalisingly interesting but I think they ran out of steam. Tim Sent from my iPhone > On 7 Dec 2018, at 06:34, Ben Coman <btc(a)openinworld.com> wrote: > > One advantage of their seemingly text-based system might be bandwidth, but Pharo is a graphical system. > It might be worthwhile for dispersed teams working on web hosted Pharo systems, but we already have remote tools. > I guess it might almost already be able to have multiple people using them simultaneously on the one image(?), but everyone would be looking at different Inpectors. > It could be cool for a common Inspector instance to show up on multiple user screens. > But is it that much better than the other suggestions?? > > cheers -ben > >> On Fri, 7 Dec 2018 at 06:03, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Santiago, >> >>> On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: >>> Would this be interesting to have in pharo?? >> >> There is already previous relevant work. Look up Kansas for Self http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI would be a major regression. Note that we already have lots fo relevant infrastructure, such as a VNC server that allows desktops to be shared. Building a shared programming environment for Pharo doesn't need to start from such limited models as the Multiplayer. >> >>> >>> What do you think? >>> >>> ---------- Forwarded message --------- >>> From: Amjad from Repl.it <contact(a)repl.it> >>> Date: jue., 6 de dic. de 2018 21:55 >>> Subject: Announcing Repl.it Multiplayer >>> To: <santiagobragagnolo(a)gmail.com> >>> >>> >>> >>> Hey Santiago, >>> >>> Professional programmers all know that software development is a fundamentally social experience. But coding remains a single-player experience by default â today, we're changing this! >>> >>> As part of our mission to make computing more accessible, we believe connecting coders, learners, and teachers together in real time, in the development environment, is a big piece of the puzzle. That's why we're proud to announce Multiplayer. >>> >>> Multiplayer lets you code with friends in the same editor, execute programs in the same interpreter, interact with the same terminal, chat in the IDE, edit files and share the same system resources, and ship applications from the same interface! We've redesigned every part of our infrastructure to work in multiplayer mode -- from the filesystem to the interpreter. >>> >>> Read more about it here, or, better yet, hop in, invite your friends and start coding! >>> Amjad from Repl.it >>> >>> 767 Bryant St, #210, San Francisco, CA 94107 >>> >>> Unsubscribe - Unsubscribe Preferences >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot

Dec. 7, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Ben Coman

One advantage of their seemingly text-based system might be bandwidth, but Pharo is a graphical system. It might be worthwhile for dispersed teams working on web hosted Pharo systems, but we already have remote tools. I guess it might almost already be able to have multiple people using them simultaneously on the one image(?), but everyone would be looking at different Inpectors. It could be cool for a common Inspector instance to show up on multiple user screens. But is it that much better than the other suggestions?? cheers -ben On Fri, 7 Dec 2018 at 06:03, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Santiago, > > On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Would this be interesting to have in pharo?? >> > > There is already previous relevant work. Look up Kansas for Self > http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak > http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI > would be a major regression. Note that we already have lots fo relevant > infrastructure, such as a VNC server that allows desktops to be shared. > Building a shared programming environment for Pharo doesn't need to start > from such limited models as the Multiplayer. > > >> >> What do you think? >> >> ---------- Forwarded message --------- >> From: Amjad from Repl.it <contact(a)repl.it> >> Date: jue., 6 de dic. de 2018 21:55 >> Subject: Announcing Repl.it Multiplayer >> To: <santiagobragagnolo(a)gmail.com> >> >> >> The official release of Repl.it Multiplayer, the collaborative coding >> experience. >> [image: Repl.it Logo] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> >> >> Hey Santiago, >> >> Professional programmers all know that software development is a >> fundamentally social experience. But coding remains a single-player >> experience by default â today, we're changing this! >> >> As part of our mission to make computing more accessible, we believe >> connecting coders, learners, and teachers together in real time, in the >> development environment, is a big piece of the puzzle. That's why we're >> proud to announce *Multiplayer*. >> >> Multiplayer lets you code with friends in the same editor, execute >> programs in the same interpreter, interact with the same terminal, chat in >> the IDE, edit files and share the same system resources, and ship >> applications from the same interface! We've redesigned every part of our >> infrastructure to work in multiplayer mode -- from the filesystem to the >> interpreter. >> [image: Repl.it Multiplayer] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> >> >> Read more about it here >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, >> or, better yet, hop in >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, >> invite your friends and start coding! >> >> Amjad from Repl.it >> >> 767 Bryant St, #210, San Francisco, CA 94107 >> >> Unsubscribe >> <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> >> - Unsubscribe Preferences >> <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Dec. 7, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Evan Donahue

Also Croquet: https://en.wikipedia.org/wiki/Croquet_Project#Open_Cobalt -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 6, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Santiago Bragagnolo

Yeah I think I see your point. I'm going to check out those projects and learn some :). Thx! El jue., 6 de dic. de 2018 23:03, Eliot Miranda <eliot.miranda(a)gmail.com> escribiÃ³: > Hi Santiago, > > On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Would this be interesting to have in pharo?? >> > > There is already previous relevant work. Look up Kansas for Self > http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak > http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI > would be a major regression. Note that we already have lots fo relevant > infrastructure, such as a VNC server that allows desktops to be shared. > Building a shared programming environment for Pharo doesn't need to start > from such limited models as the Multiplayer. > > >> >> What do you think? >> >> ---------- Forwarded message --------- >> From: Amjad from Repl.it <contact(a)repl.it> >> Date: jue., 6 de dic. de 2018 21:55 >> Subject: Announcing Repl.it Multiplayer >> To: <santiagobragagnolo(a)gmail.com> >> >> >> The official release of Repl.it Multiplayer, the collaborative coding >> experience. >> [image: Repl.it Logo] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> >> >> Hey Santiago, >> >> Professional programmers all know that software development is a >> fundamentally social experience. But coding remains a single-player >> experience by default â today, we're changing this! >> >> As part of our mission to make computing more accessible, we believe >> connecting coders, learners, and teachers together in real time, in the >> development environment, is a big piece of the puzzle. That's why we're >> proud to announce *Multiplayer*. >> >> Multiplayer lets you code with friends in the same editor, execute >> programs in the same interpreter, interact with the same terminal, chat in >> the IDE, edit files and share the same system resources, and ship >> applications from the same interface! We've redesigned every part of our >> infrastructure to work in multiplayer mode -- from the filesystem to the >> interpreter. >> [image: Repl.it Multiplayer] >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> >> >> Read more about it here >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, >> or, better yet, hop in >> <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, >> invite your friends and start coding! >> >> Amjad from Repl.it >> >> 767 Bryant St, #210, San Francisco, CA 94107 >> >> Unsubscribe >> <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> >> - Unsubscribe Preferences >> <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Dec. 6, 2018

Re: [Pharo-dev] Fwd: Announcing Repl.it Multiplayer

by Eliot Miranda

Hi Santiago, On Thu, Dec 6, 2018 at 1:52 PM Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > Would this be interesting to have in pharo?? > There is already previous relevant work. Look up Kansas for Self http://wiki.squeak.org/squeak/1357 and Nebraska for Squeak http://wiki.squeak.org/squeak/1356. Focussing on the Multiplayer like UI would be a major regression. Note that we already have lots fo relevant infrastructure, such as a VNC server that allows desktops to be shared. Building a shared programming environment for Pharo doesn't need to start from such limited models as the Multiplayer. > > What do you think? > > ---------- Forwarded message --------- > From: Amjad from Repl.it <contact(a)repl.it> > Date: jue., 6 de dic. de 2018 21:55 > Subject: Announcing Repl.it Multiplayer > To: <santiagobragagnolo(a)gmail.com> > > > The official release of Repl.it Multiplayer, the collaborative coding > experience. > [image: Repl.it Logo] > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> > > Hey Santiago, > > Professional programmers all know that software development is a > fundamentally social experience. But coding remains a single-player > experience by default â today, we're changing this! > > As part of our mission to make computing more accessible, we believe > connecting coders, learners, and teachers together in real time, in the > development environment, is a big piece of the puzzle. That's why we're > proud to announce *Multiplayer*. > > Multiplayer lets you code with friends in the same editor, execute > programs in the same interpreter, interact with the same terminal, chat in > the IDE, edit files and share the same system resources, and ship > applications from the same interface! We've redesigned every part of our > infrastructure to work in multiplayer mode -- from the filesystem to the > interpreter. > [image: Repl.it Multiplayer] > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> > > Read more about it here > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, > or, better yet, hop in > <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, > invite your friends and start coding! > > Amjad from Repl.it > > 767 Bryant St, #210, San Francisco, CA 94107 > > Unsubscribe > <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> > - Unsubscribe Preferences > <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…> > -- _,,,^..^,,,_ best, Eliot

Dec. 6, 2018

Fwd: Announcing Repl.it Multiplayer

by Santiago Bragagnolo

Would this be interesting to have in pharo?? What do you think? ---------- Forwarded message --------- From: Amjad from Repl.it <contact(a)repl.it> Date: jue., 6 de dic. de 2018 21:55 Subject: Announcing Repl.it Multiplayer To: <santiagobragagnolo(a)gmail.com> The official release of Repl.it Multiplayer, the collaborative coding experience. [image: Repl.it Logo] <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy0-2F0rOvSNWPLVoxcc…> Hey Santiago, Professional programmers all know that software development is a fundamentally social experience. But coding remains a single-player experience by default â today, we're changing this! As part of our mission to make computing more accessible, we believe connecting coders, learners, and teachers together in real time, in the development environment, is a big piece of the puzzle. That's why we're proud to announce *Multiplayer*. Multiplayer lets you code with friends in the same editor, execute programs in the same interpreter, interact with the same terminal, chat in the IDE, edit files and share the same system resources, and ship applications from the same interface! We've redesigned every part of our infrastructure to work in multiplayer mode -- from the filesystem to the interpreter. [image: Repl.it Multiplayer] <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…> Read more about it here <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy2nGqoz6hoT3s1h4Iok…>, or, better yet, hop in <http://url1361.repl.it/wf/click?upn=LLQySNMYKcsdrD3Xpw6uy7y9lyv5Ff-2FoVbyQr…>, invite your friends and start coding! Amjad from Repl.it 767 Bryant St, #210, San Francisco, CA 94107 Unsubscribe <http://url1361.repl.it/asm/unsubscribe/?user_id=8107274&data=346ff9QOfXR57C…> - Unsubscribe Preferences <http://url1361.repl.it/asm/?user_id=8107274&data=USDh4jRtVtwga9cUFmXIXfBZ19…>

Dec. 6, 2018

[Pharo 7.0] Build #21: 22733-Some-menubar-cleaning

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

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

Dec. 6, 2018

[Pharo 7.0] Build #20: 22313-Packages-are-created-for-extension-methods-that-does-not-are-exactly-the-package-name

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

There is a new Pharo build available! The status of the build #20 was: SUCCESS. The Pull Request #1741 was integrated: "22313-Packages-are-created-for-extension-methods-that-does-not-are-exactly-the-package-name" Pull request url: https://github.com/pharo-project/pharo/pull/1741 Issue Url: https://pharo.fogbugz.com/f/cases/22313 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 6, 2018

OSSubprocess equivalent in Pharo7?

by Hans-Martin

Hello, I noticed that theOSSubprocess functionality for communicating with OS subprocesses depends on OSSAttachableFileStream which is a subclass of deprecated FileStream (incidentally, the project is not marked as being compatible with Pharo7). The popen()/fgetc() based examples in UNIXProcess are blocking, which is unusable for any but the most basic external command executions. Are there plans to implement a proper replacement in Pharo7? Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Thu, 6 Dec 2018 at 01:25, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Esteban, Ronie, > Forking, branching and merging is certainly the clean way to do it! > The question is about the frequency of merges. Like Ben I prefer short > cycles, because otherwise we just can't review the code, it' too many diffs > at once. We can just trust, or not, take it or leave it... > So who is going to take the responsibility? > > How i did it for win64 support? The canonicle way would have been to > develop a long branch with hundreds of changed files/lines, then merge when > ready. Instead of that, i integrated small batches of changes, none of > which were sufficient to have win64 working, but none of which completely > broke the trunk. Small steps... I know some purists that don't like my way > of doing because we obtain interleaved features in the history preventing > to easily bissect regressions, but i don't like puritanism either :). > > In fact, i did experiment like Ronie in my own private fork, then when > ready, (not when perfect, but just when it reached a minimum of usability), > i redone everything in smaller steps (cherry pick, rebase, squash, > whatever...). > > I did also commit some changes in trunk, or accepted my own merge, which > is questionable, but IMO more acceptable than rotting PR: that just means > that i have to assume the responsibility of changes, I break it, I repair > it. Ronie, you could adopt such strategy too, because in some aspects of > the VM, you are the expert :)! > > It's certainly easier to concentrate on own changes and forget about the > drag of legacy, but it's only a short term view. The burden of integration > is differed, not eliminated, and the impact of changes not really mastered, > because at the end we say let's integrate now and see later what is > broken... We cannot always avoid such strategy when legacy code is too much > intricated... But in this case, my own view of refactoring is untwist > first, then replace. > > I don't want to discourage good will, on the contrary, thanks a lot for > taking the burden of these essential changes!!! I rather want to encourage > more frequent refactorings. Don't hesitate to flood opensmalltalk with > small PR. > An enlightening moment for me was reading an article about how PRs should not just be for the final product to integrate, but also be used heavily for discussion. Just put prepend something like "WIP" to the title. Then the PR is updated every time you commit to your source branch. There is even a github app to help manage that... https://github.com/wip/app#configuration https://github.com/wip/app/blob/master/pro-plan-for-free.js The "compare" tool is then available to draw attention to particular changes between particular commits... https://help.github.com/articles/comparing-commits-across-time/ cheers -ben They don't need to be perfect nor complete, as long as they go in the right > direction. > > Smaller changes means less burden and less responsibility for the > integrators, so more people can effectively integrate, not just Eliot or > Ben. > > Cheers and thanks again! > > > > Le 5 dÃ©c. 2018 16:29, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : > > > > On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi Eliot, >> >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> Iâm slowly working on that VM because we want it to be the default for >> Pharo 8. >> In our vision, it should be a responsibility of the image to start or not >> a graphical UI, so we are preparing (we have been preparing to it for >> years, actually) to achieve this behaviour. >> To make this work, we need all platforms covered (and another huge >> quantity of changes here and there). >> Anyway, I didnât merge because I wanted to have win64 covered, not just >> what we have now, and since no-one was using that VM I didnât feel pression >> to do it :) >> >> >> How does that answer Norbertâs question? By doing the work in your own >> fork you risk forking. Do you want to fork? If not, why not do the work >> in opensmalltalk-vm? >> >> I guess you mean "why not do the work directly on the Cog branch of the > OpenSmalltalk accountâ, > > > Thatâs not how you work on git/github and I prefer to keep it âas > intendedâ. > > because any other branch is no different to any other branch regardless of > which account its stored in. > The "opensmaltalk-vm repo" is a single big commit graph across all > accounts, as you can see... > https://github.com/OpenSmalltalk/opensmalltalk-vm/network > > Whether any development-branch becomes a real-fork in the old vernacular > is not how long it stays unmerged from the mainline-branch > but how often the development-branch is updated to merge in the > mainline-branch. The network graph is useful to understand the situation > here. > > > This is old thing (there is a pull request now, since like 3 weeks). >> I worked on my fork because thatâs how you do it with git: you fork, you >> work, and you do a Pull Request when ready. >> I was explaining why the PR was not still done: I wanted to have covered >> the three platforms before doing it. >> > > On the flip side, release early release is a good policy. > > > Yeah, but for that you need to have something that you can release. > minheadless was developed by Ronie (I just made the makefiles and adapted > to build pharovms). And then it stalled around until I decided to took it > and merge itâ¦ Iâm going to be susceptible and say that frankly I do not > understand the tone of this mails. > > It was your merge of minheadless into Cog that stimulated me to add my > minor minheadless tweaks. > > > And Iâm grateful :) > > I know I could have submitted a PR direct to your minheadless branch, but > somehow it just felt more comfortable > submitting it to the mainline Cog branch. > > >> >> I guess the terminology is confusing you? >> > > That doesn't help. > > > Why? Terminology *is* confusing, at least for me. > > Esteban > > > cheers -ben > > > >

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Nicolas Cellier

Hi Esteban, Ronie, Forking, branching and merging is certainly the clean way to do it! The question is about the frequency of merges. Like Ben I prefer short cycles, because otherwise we just can't review the code, it' too many diffs at once. We can just trust, or not, take it or leave it... So who is going to take the responsibility? How i did it for win64 support? The canonicle way would have been to develop a long branch with hundreds of changed files/lines, then merge when ready. Instead of that, i integrated small batches of changes, none of which were sufficient to have win64 working, but none of which completely broke the trunk. Small steps... I know some purists that don't like my way of doing because we obtain interleaved features in the history preventing to easily bissect regressions, but i don't like puritanism either :). In fact, i did experiment like Ronie in my own private fork, then when ready, (not when perfect, but just when it reached a minimum of usability), i redone everything in smaller steps (cherry pick, rebase, squash, whatever...). I did also commit some changes in trunk, or accepted my own merge, which is questionable, but IMO more acceptable than rotting PR: that just means that i have to assume the responsibility of changes, I break it, I repair it. Ronie, you could adopt such strategy too, because in some aspects of the VM, you are the expert :)! It's certainly easier to concentrate on own changes and forget about the drag of legacy, but it's only a short term view. The burden of integration is differed, not eliminated, and the impact of changes not really mastered, because at the end we say let's integrate now and see later what is broken... We cannot always avoid such strategy when legacy code is too much intricated... But in this case, my own view of refactoring is untwist first, then replace. I don't want to discourage good will, on the contrary, thanks a lot for taking the burden of these essential changes!!! I rather want to encourage more frequent refactorings. Don't hesitate to flood opensmalltalk with small PR. They don't need to be perfect nor complete, as long as they go in the right direction. Smaller changes means less burden and less responsibility for the integrators, so more people can effectively integrate, not just Eliot or Ben. Cheers and thanks again! Le 5 dÃ©c. 2018 16:29, "Esteban Lorenzano" <estebanlm(a)gmail.com> a Ã©crit : On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for > Pharo 8. > In our vision, it should be a responsibility of the image to start or not > a graphical UI, so we are preparing (we have been preparing to it for > years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge > quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just > what we have now, and since no-one was using that VM I didnât feel pression > to do it :) > > > How does that answer Norbertâs question? By doing the work in your own > fork you risk forking. Do you want to fork? If not, why not do the work > in opensmalltalk-vm? > > I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk accountâ, Thatâs not how you work on git/github and I prefer to keep it âas intendedâ. because any other branch is no different to any other branch regardless of which account its stored in. The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here. This is old thing (there is a pull request now, since like 3 weeks). > I worked on my fork because thatâs how you do it with git: you fork, you > work, and you do a Pull Request when ready. > I was explaining why the PR was not still done: I wanted to have covered > the three platforms before doing it. > On the flip side, release early release is a good policy. Yeah, but for that you need to have something that you can release. minheadless was developed by Ronie (I just made the makefiles and adapted to build pharovms). And then it stalled around until I decided to took it and merge itâ¦ Iâm going to be susceptible and say that frankly I do not understand the tone of this mails. It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. And Iâm grateful :) I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable submitting it to the mainline Cog branch. > > I guess the terminology is confusing you? > That doesn't help. Why? Terminology *is* confusing, at least for me. Esteban cheers -ben

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Eliot Miranda

Hi Esteban, On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for > Pharo 8. > In our vision, it should be a responsibility of the image to start or not > a graphical UI, so we are preparing (we have been preparing to it for > years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge > quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just > what we have now, and since no-one was using that VM I didnât feel pression > to do it :) > > > How does that answer Norbertâs question? By doing the work in your own > fork you risk forking. Do you want to fork? If not, why not do the work > in opensmalltalk-vm? > > > This is old thing (there is a pull request now, since like 3 weeks). > Ah, OK. I should;d have checked the dates more carefully. > I worked on my fork because thatâs how you do it with git: you fork, you > work, and you do a Pull Request when ready. > I hope you forked opensmalltalk-vm not pharo-vm/opensmalltalk-vm, that's all. > I was explaining why the PR was not still done: I wanted to have covered > the three platforms before doing it. > > I guess the terminology is confusing you? > I get forking in a single repository. I also get forking across repositories. These are two different things. I had misunderstood where you were forking. I apologize. > > Cheers! > Esteban > > > > Cheers, > Esteban > > > On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > What keeps you from doing a pull request to opensmalltalk-vm ? > > Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > Hi Ben, > > Sorry for coming here so late, I didnât see this thread before. > I already have a working minheadless branch that was adapted to Eliotâs > process. > It was working for Pharo in Linux and Mac (Windows was ongoing but not > finished, thatâs why is not pushed). > > You can find this branch here: > > https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm > > Interesting part is that I didnât tackled any of the issues you are > working on, so the work is easily mergeable :) > > Cheers, > Esteban > > Ps: with some changes in image, Iâm using exclusively this VM since a > couple of months and it works fine. > > > On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com> wrote: > > On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> Hi Ben, >> > Feel free to make this edit and commit >> > > I'm pushing changes here... > > https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… > > and the diff can be tracked here... > > https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… > > > ------------------------ > On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: > >> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int >> awareness); >> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >> E0651 a calling convention may not be followed by a nested declarator. >> >> The following change reduces build errors to 1... >> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int >> awareness); >> >> but I'm not sure of the implications. > > > I found the correct solution to this... > "The trick is placing the [call declaration] inside the parentheses" > > https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… > > i.e. the following compiles cleanly > typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int > awareness); > > > ----------------------------- > Now running the VM (without parameters) I get... > Debug Assertion Failed! > Program: ...\x64-Debug\dist\pharo.exe > File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c > Line: 106 > Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 > > at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | > _MCW_IC); > > https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… > > > According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx > x64 does not support _MCW_PC or _MCW_IC > but I'm clueless about the implications of these FPU flags. > Could our math guys please advise? > > Eliminating those two flags allows a VM run successfully without loading > an Image. > i.e. it successfully passes... > osvm_initialize(); > osvm_parseCommandLineArguments(argc, argv); > osvm_initializeVM(); > > Next is to try loading an Image. > > cheers -ben > > > > > -- _,,,^..^,,,_ best, Eliot

Dec. 5, 2018

[Pharo 7.0] Build #19: 22731-notification-mail-has-an-error-on-version

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

There is a new Pharo build available! The status of the build #19 was: SUCCESS. The Pull Request #2043 was integrated: "22731-notification-mail-has-an-error-on-version" Pull request url: https://github.com/pharo-project/pharo/pull/2043 Issue Url: https://pharo.fogbugz.com/f/cases/22731 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Wed, 5 Dec 2018 at 23:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi Eliot, >> >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> Iâm slowly working on that VM because we want it to be the default for >> Pharo 8. >> In our vision, it should be a responsibility of the image to start or not >> a graphical UI, so we are preparing (we have been preparing to it for >> years, actually) to achieve this behaviour. >> To make this work, we need all platforms covered (and another huge >> quantity of changes here and there). >> Anyway, I didnât merge because I wanted to have win64 covered, not just >> what we have now, and since no-one was using that VM I didnât feel pression >> to do it :) >> >> >> How does that answer Norbertâs question? By doing the work in your own >> fork you risk forking. Do you want to fork? If not, why not do the work >> in opensmalltalk-vm? >> >> I guess you mean "why not do the work directly on the Cog branch of the > OpenSmalltalk accountâ, > > > Thatâs not how you work on git/github and I prefer to keep it âas > intendedâ. > > because any other branch is no different to any other branch regardless of > which account its stored in. > The "opensmaltalk-vm repo" is a single big commit graph across all > accounts, as you can see... > https://github.com/OpenSmalltalk/opensmalltalk-vm/network > > Whether any development-branch becomes a real-fork in the old vernacular > is not how long it stays unmerged from the mainline-branch > but how often the development-branch is updated to merge in the > mainline-branch. The network graph is useful to understand the situation > here. > > > This is old thing (there is a pull request now, since like 3 weeks). >> I worked on my fork because thatâs how you do it with git: you fork, you >> work, and you do a Pull Request when ready. >> I was explaining why the PR was not still done: I wanted to have covered >> the three platforms before doing it. >> > > On the flip side, release early release is a good policy. > > > Yeah, but for that you need to have something that you can release. > minheadless was developed by Ronie (I just made the makefiles and adapted > to build pharovms). And then it stalled around until I decided to took it > and merge itâ¦ Iâm going to be susceptible and say that frankly I do not > understand the tone of this mails. > > It was your merge of minheadless into Cog that stimulated me to add my > minor minheadless tweaks. > > > And Iâm grateful :) > > I know I could have submitted a PR direct to your minheadless branch, but > somehow it just felt more comfortable > submitting it to the mainline Cog branch. > > >> >> I guess the terminology is confusing you? >> > > That doesn't help. > > > Why? Terminology *is* confusing, at least for me. > It came across sarcastic. My apologies. Email is a poor medium sometimes. cheers -ben

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

> On 5 Dec 2018, at 16:19, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi Eliot, > >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> Iâm slowly working on that VM because we want it to be the default for Pharo 8. >>> In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. >>> To make this work, we need all platforms covered (and another huge quantity of changes here and there). >>> Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) >> >> How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? > > I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk accountâ, Thatâs not how you work on git/github and I prefer to keep it âas intendedâ. > because any other branch is no different to any other branch regardless of which account its stored in. > The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network <https://github.com/OpenSmalltalk/opensmalltalk-vm/network> > > Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch > but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here. > > > This is old thing (there is a pull request now, since like 3 weeks). > I worked on my fork because thatâs how you do it with git: you fork, you work, and you do a Pull Request when ready. > I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it. > > On the flip side, release early release is a good policy. Yeah, but for that you need to have something that you can release. minheadless was developed by Ronie (I just made the makefiles and adapted to build pharovms). And then it stalled around until I decided to took it and merge itâ¦ Iâm going to be susceptible and say that frankly I do not understand the tone of this mails. > It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. And Iâm grateful :) > I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable > submitting it to the mainline Cog branch. > > > I guess the terminology is confusing you? > > That doesn't help. Why? Terminology *is* confusing, at least for me. Esteban > > cheers -ben

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for > Pharo 8. > In our vision, it should be a responsibility of the image to start or not > a graphical UI, so we are preparing (we have been preparing to it for > years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge > quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just > what we have now, and since no-one was using that VM I didnât feel pression > to do it :) > > > How does that answer Norbertâs question? By doing the work in your own > fork you risk forking. Do you want to fork? If not, why not do the work > in opensmalltalk-vm? > > I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk account", because any other branch is no different to any other branch regardless of which account its stored in. The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here. This is old thing (there is a pull request now, since like 3 weeks). > I worked on my fork because thatâs how you do it with git: you fork, you > work, and you do a Pull Request when ready. > I was explaining why the PR was not still done: I wanted to have covered > the three platforms before doing it. > On the flip side, release early release is a good policy. It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable submitting it to the mainline Cog branch. > > I guess the terminology is confusing you? > That doesn't help. cheers -ben

Dec. 5, 2018

[Pharo .0] Build #18: 22726 pharo icon in menus is larger than other icons 20 pix instead of 16 making its row height different

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

There is a new Pharo build available! The status of the build #18 was: SUCCESS. The Pull Request #2037 was integrated: "22726 pharo icon in menus is larger than other icons 20 pix instead of 16 making its row height different" Pull request url: https://github.com/pharo-project/pharo/pull/2037 Issue Url: https://pharo.fogbugz.com/f/cases/22726 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

Re: [Pharo-dev] [IMPORTANT] Development branch changed to "Pharo7.0"

by Esteban Lorenzano

I forgot to explain that at the end we choose to name our branches âPharoMAJOR.MINORâ instead âdev-MAJOR.MINORâ as proposed at first because that way was not clear what the branches are. Yes, they are development branches, but they also have the released versions (usually as tags). After searching some other projects with similar characteristics to ours, we think this was the better approach. Esteban > On 5 Dec 2018, at 15:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Working on Pharo7.0 release, I finally changed the default branch. > âDevelopment" does not exists anymore, now all Pull Requests needs to be done against âPharo7.0â. > > This will allow us to : > > - Continue working on Pharo7.0 release > - Open a Pharo8.0 branch (hopefully next week) > > Iâm sorry for the mess I can cause to someones, there should not be a problem for most of you but some may need to update their scripts. > > Cheers! > Esteban

Dec. 5, 2018

[IMPORTANT] Development branch changed to "Pharo7.0"

by Esteban Lorenzano

Hi, Working on Pharo7.0 release, I finally changed the default branch. âDevelopment" does not exists anymore, now all Pull Requests needs to be done against âPharo7.0â. This will allow us to : - Continue working on Pharo7.0 release - Open a Pharo8.0 branch (hopefully next week) Iâm sorry for the mess I can cause to someones, there should not be a problem for most of you but some may need to update their scripts. Cheers! Esteban

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Esteban Lorenzano

Hi Eliot, > On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> Iâm slowly working on that VM because we want it to be the default for Pharo 8. >> In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. >> To make this work, we need all platforms covered (and another huge quantity of changes here and there). >> Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) > > How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? This is old thing (there is a pull request now, since like 3 weeks). I worked on my fork because thatâs how you do it with git: you fork, you work, and you do a Pull Request when ready. I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it. I guess the terminology is confusing you? Cheers! Esteban > >> >> Cheers, >> Esteban >> >> >>> On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >>> What keeps you from doing a pull request to opensmalltalk-vm ? >>> >>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>>> Hi Ben, >>>> >>>> Sorry for coming here so late, I didnât see this thread before. >>>> I already have a working minheadless branch that was adapted to Eliotâs process. >>>> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >>>> >>>> You can find this branch here: >>>> >>>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm <https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm> >>>> >>>> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >>>> >>>> Cheers, >>>> Esteban >>>> >>>> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >>>> >>>> >>>>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> >>>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>>> >>>>> Hi Ben, >>>>> Feel free to make this edit and commit >>>>> >>>>> I'm pushing changes here... >>>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… <https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-…> >>>>> >>>>> and the diff can be tracked here... >>>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… <https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..…> >>>>> >>>>> >>>>> ------------------------ >>>>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>>> E0651 a calling convention may not be followed by a nested declarator. >>>>> >>>>> The following change reduces build errors to 1... >>>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> but I'm not sure of the implications. >>>>> >>>>> I found the correct solution to this... >>>>> "The trick is placing the [call declaration] inside the parentheses" >>>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… <https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co…> >>>>> >>>>> i.e. the following compiles cleanly >>>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> >>>>> ----------------------------- >>>>> Now running the VM (without parameters) I get... >>>>> Debug Assertion Failed! >>>>> Program: ...\x64-Debug\dist\pharo.exe >>>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>>> Line: 106 >>>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>>> >>>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… <https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea…> >>>>> >>>>> >>>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx <https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx> >>>>> x64 does not support _MCW_PC or _MCW_IC >>>>> but I'm clueless about the implications of these FPU flags. >>>>> Could our math guys please advise? >>>>> >>>>> Eliminating those two flags allows a VM run successfully without loading an Image. >>>>> i.e. it successfully passes... >>>>> osvm_initialize(); >>>>> osvm_parseCommandLineArguments(argc, argv); >>>>> osvm_initializeVM(); >>>>> >>>>> Next is to try loading an Image. >>>>> >>>>> cheers -ben >>>> >>

Dec. 5, 2018

Re: [Pharo-dev] Minheadless trial

by Eliot Miranda

Hi Esteban, > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Iâm slowly working on that VM because we want it to be the default for Pharo 8. > In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. > To make this work, we need all platforms covered (and another huge quantity of changes here and there). > Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :) How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm? > > Cheers, > Esteban > > >> On 7 Aug 2018, at 08:50, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> What keeps you from doing a pull request to opensmalltalk-vm ? >> >>> Am 07.08.2018 um 07:47 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> Hi Ben, >>> >>> Sorry for coming here so late, I didnât see this thread before. >>> I already have a working minheadless branch that was adapted to Eliotâs process. >>> It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, thatâs why is not pushed). >>> >>> You can find this branch here: >>> >>> https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm >>> >>> Interesting part is that I didnât tackled any of the issues you are working on, so the work is easily mergeable :) >>> >>> Cheers, >>> Esteban >>> >>> Ps: with some changes in image, Iâm using exclusively this VM since a couple of months and it works fine. >>> >>> >>>> On 7 Aug 2018, at 07:22, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> On 7 August 2018 at 05:12, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>> >>>>> Hi Ben, >>>>> Feel free to make this edit and commit >>>> >>>> I'm pushing changes here... >>>> https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… >>>> >>>> and the diff can be tracked here... >>>> https://github.com/bencoman/opensmalltalk-vm/compare/MinimalisticHeadless..… >>>> >>>> >>>> ------------------------ >>>>> On 6 August 2018 at 13:22, Ben Coman <btc(a)openinworld.com> wrote: >>>>> On 6 August 2018 at 11:50, Ben Coman <btc(a)openinworld.com> wrote: >>>>> >>>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >>>>> typedef HRESULT WINAPI (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> C2059 sqPlatformSpecific-Win32.c:80 syntax error: '(' >>>>> E0651 a calling convention may not be followed by a nested declarator. >>>>> >>>>> The following change reduces build errors to 1... >>>>> typedef HRESULT (*SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>>> >>>>> but I'm not sure of the implications. >>>> >>>> I found the correct solution to this... >>>> "The trick is placing the [call declaration] inside the parentheses" >>>> https://stackoverflow.com/questions/4830355/function-pointer-and-calling-co… >>>> >>>> i.e. the following compiles cleanly >>>> typedef HRESULT (WINAPI *SetProcessDpiAwarenessFunctionPointer) (int awareness); >>>> >>>> >>>> ----------------------------- >>>> Now running the VM (without parameters) I get... >>>> Debug Assertion Failed! >>>> Program: ...\x64-Debug\dist\pharo.exe >>>> File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c >>>> Line: 106 >>>> Expression: (mask&~(_MCW_DN | _MCW_EM | _MCW_RC))==0 >>>> >>>> at the call to _controlfp(FPU_DEFAULT, _MCW_EM | _MCW_RC | _MCW_PC | _MCW_IC); >>>> https://github.com/ronsaldo/opensmalltalk-vm/blob/be7b1c03/platforms/minhea… >>>> >>>> >>>> According to https://msdn.microsoft.com/en-us/library/e9b52ceh.aspx >>>> x64 does not support _MCW_PC or _MCW_IC >>>> but I'm clueless about the implications of these FPU flags. >>>> Could our math guys please advise? >>>> >>>> Eliminating those two flags allows a VM run successfully without loading an Image. >>>> i.e. it successfully passes... >>>> osvm_initialize(); >>>> osvm_parseCommandLineArguments(argc, argv); >>>> osvm_initializeVM(); >>>> >>>> Next is to try loading an Image. >>>> >>>> cheers -ben >>> >

Dec. 5, 2018

[Pharo .0] Build #17: SUCCESS

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

There is a new Pharo build available! The status of the build #17 was: SUCCESS. Could not extract further issue information from commit message: restore uploads Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo .0] Build #16: SUCCESS

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

There is a new Pharo build available! The status of the build #16 was: SUCCESS. Could not extract further issue information from commit message: dix sources when converting to 64bit too Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo 7.0-dev] Build #1436: Improving comment of class DebugSession

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

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

Dec. 5, 2018

[Pharo .0] Build #15: FAILURE

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

There is a new Pharo build available! The status of the build #15 was: FAILURE. Could not extract further issue information from commit message: fix inclusion of sources suspend upload for the moment = Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 5, 2018

[Pharo .0] Build #14: SUCCESS

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

There is a new Pharo build available! The status of the build #14 was: SUCCESS. Could not extract further issue information from commit message: groovy is zero based :( Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 4, 2018

[Pharo 7.0-dev] Build #1435: 22727-NonInteractiveTranscript-is-broken-with-files

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

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

Dec. 4, 2018

Re: [Pharo-dev] InterruptedContext vs suspendedContext

by Thomas Dupriez

Ok, thanks to you two for these nice answers. I made a pull-request to improve the comment of the DebugSession class based on your answers. Thomas On 01/12/2018 19:02, Eliot Miranda wrote: > Hi Andrei, Hi Thomas, > > Â Â Andrei, you are right; they are different and the difference is > important. Â As you say, suspendedContext is the top (âhotâ) context in > a processâs context chain, but interruptedContext is the context which > sent the signal message that eventually raised the exception that > invoked the debugger. Â suspendedContext is therefore where execution > is in the process, but interruptedContext is where the debugger should > show the stack. > > Thomas, because the exception system is implemented in Smalltalk the > handling of the initial signal (eg in Object>>#halt), all the way to > opening a debugger, is itself Smalltalk code, and exists as > activations from suspendedContext toÂ interruptedContext. Â The > debugger, with help from the exception system, carefully hides this > processing from the programmer. Â If it did not we would have to wade > through many activations before we found where the exception occurred. > > When a process is interrupted by control period things are different. > Â Here, another process handles opening the debugger and indeed > suspendedContext and interruptedContext are the same. > > So the difference between suspendedContext and interruptedContext is > vital to the debugger. Â Without it we would Â see the inner machinery > of the exception system when errors or exceptions are raised. > > HTH > > _,,,^..^,,,_ (phone) > > On Nov 30, 2018, at 7:42 AM, Andrei Chis <chisvasileandrei(a)gmail.com > <mailto:chisvasileandrei@gmail.com>> wrote: > >> Hi, >> >> From what I remember they are not always redundant, but I'm not 100% >> sure they are both needed. >> >> `suspendedContext` from Process is always the top context of a >> process. After execution actions like Step Into, Step Over, Step >> Through it will be the same as interruptedContext in the debugger. >> >> They will be different when opening the debugger as a result of an >> exception. >> Exception>>#debug triggers the workflow for opening a debugger. This >> uses `self signalerContext` as the context that is being debugged. >> This is the context where the exception was raised and this will be >> put in the interruptedContext. As this point the execution of the >> current process is not over and it will continue up to >> `MorphicUIManager>>#debugProcess:context:label:fullView:notification:Â ` >> where the current process is suspended. At that point the two will be >> different, as suspendedContext will be the context of the method >> MorphicUIManager>>#debugProcess:context:label:fullView:notification: >> and the interruptedContext the context that triggered the exception. >> >> But it might be that they are not both needed. OneÂ possible option >> might be to force the process to step to the context that raised the >> exception when the debugger is created. For example >> inÂ DebugSession>>process:context:. >> Apart from when opening the debugger I do not know if there is >> another situation where those two can diverge. >> >> Cheers, >> Andrei >> >> On Fri, Nov 30, 2018 at 11:54 AM Thomas Dupriez >> <tdupriez(a)ens-paris-saclay.fr <mailto:tdupriez@ens-paris-saclay.fr>> >> wrote: >> >> Hello, >> >> >> Instances of DebugSession have an "interruptedContext" and an >> "interruptedProcess" instance variable. >> >> Instances of Process have a "suspendedContext" instance variable. >> >> Does someone know if there is a relation between the >> interruptedContext of a DebugSession and the suspendedContext of >> its interruptedProcess? At first glance it seems like these two >> variables are redundant and store the same Context. >> >> Thomas Dupriez >>

Dec. 4, 2018

[Pharo 7.0-dev] Build #1434: 22687-Update-Tonel

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

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

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Andrei Chis

Super. I can also help if you need so. On Mon, Dec 3, 2018 at 3:59 PM Julien <julien.delplanque(a)inria.fr> wrote: > Sure, I will keep the history. > > I will see how much time it takes to migrate PetitParser. > > If it does not take too much time, maybe I will do it for the two others > repository. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > Le 3 dÃ©c. 2018 Ã 15:55, Andrei Chis <chisvasileandrei(a)gmail.com> a Ã©crit : > > Hi, > > That's definitely a good idea. > > Just would also be very nice to use Peter's migration tool to also capture > the history+authors. > (I can provide you with a lis of authors that for the migration tool that > should cover most authors from PetitParser). > > If you're at this, could also help to migrate the PetitSQLite and > PetitJava projects. > > Cheers, > Andrei > > > On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr> wrote: > >> Hello, >> >> Iâd like to migrate PetitParser (1) on GitHub under moosetechnology >> organisation. >> >> I have a project depending on it and there are some stuff Iâd like to fix >> on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). >> >> Is it ok to migrate it? >> >> Cheers, >> >> Julien >> >> --- >> Julien Delplanque >> Doctorant Ã lâUniversitÃ© de Lille >> http://juliendelplanque.be/phd.html >> Equipe Rmod, Inria >> BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq >> NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Re: Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Julien

Sure, I will keep the history. I will see how much time it takes to migrate PetitParser. If it does not take too much time, maybe I will do it for the two others repository. Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 3 dÃ©c. 2018 Ã 15:55, Andrei Chis <chisvasileandrei(a)gmail.com> a Ã©crit : > > Hi, > > That's definitely a good idea. > > Just would also be very nice to use Peter's migration tool to also capture the history+authors. > (I can provide you with a lis of authors that for the migration tool that should cover most authors from PetitParser). > > If you're at this, could also help to migrate the PetitSQLite and PetitJava projects. > > Cheers, > Andrei > > > On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>> wrote: > Hello, > > Iâd like to migrate PetitParser (1) on GitHub under moosetechnology organisation. > > I have a project depending on it and there are some stuff Iâd like to fix on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). > > Is it ok to migrate it? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html <http://juliendelplanque.be/phd.html> > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> > https://www.list.inf.unibe.ch/listinfo/moose-dev <https://www.list.inf.unibe.ch/listinfo/moose-dev> > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 3, 2018

Re: [Pharo-dev] [Moose-dev] Migrate PetitParser (1) on GitHub under moosetechnology organisation?

by Andrei Chis

Hi, That's definitely a good idea. Just would also be very nice to use Peter's migration tool to also capture the history+authors. (I can provide you with a lis of authors that for the migration tool that should cover most authors from PetitParser). If you're at this, could also help to migrate the PetitSQLite and PetitJava projects. Cheers, Andrei On Mon, Dec 3, 2018 at 3:41 PM Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > Iâd like to migrate PetitParser (1) on GitHub under moosetechnology > organisation. > > I have a project depending on it and there are some stuff Iâd like to fix > on PetitParser 1 ConfigurationOf (which will become a baseline on GitHub). > > Is it ok to migrate it? > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 3, 2018