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

[Pharo 7.0] Build #38: 22767 Categorize uncategorized classes in Tool-Finder

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

There is a new Pharo build available! The status of the build #38 was: SUCCESS. The Pull Request #2070 was integrated: "22767 Categorize uncategorized classes in Tool-Finder" Pull request url: https://github.com/pharo-project/pharo/pull/2070 Issue Url: https://pharo.fogbugz.com/f/cases/22767 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

[Pharo 7.0] Build #37: 22766-Transcript-window-is-leaking

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

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

Dec. 14, 2018

glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Things are moving fast in the glamorous land. We now reached v0.4.0: https://gtoolkit.com There are several significant advances in this version. The first thing to note is that v0.4.0 is a reproducible version that can be loaded with: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit:v0.4.0/src'; load. https://github.com/feenkcom/gtoolkit/releases/tag/v0.4.0 The version was created with Releaser the new member of GT that is able to release deeply nested projects: https://twitter.com/girba/status/1073407418460225536 The rest of the environment has seen a few key changes as well: - Documenter received support for dynamic markup edit. This is an almost magic ability that makes the markup appear when the cursor nears the markup. With this we have reached a seamless experience that supports both viewing without markup and editing on demand. https://twitter.com/feenkcom/status/1067879286143676419 - Playground uses Coder and snippets are now collapsable. https://twitter.com/feenkcom/status/1070806168459767809 - The Inspector updates when the code changes. https://twitter.com/feenkcom/status/1072581283925159936 https://twitter.com/feenkcom/status/1072107898900238337 - The Meta view from Inspector was enhanced to show the super classes and method categories, each of these act list filters. On top of that, we can also filter methods by name. https://twitter.com/feenkcom/status/1072223641583149057 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/2?closed=1 Please do let us know what you think .. and, of course, what you feel. Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > >> Le 13 dÃ©c. 2018 Ã 17:31, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >> >> Ciao, >> >>> Hi, >>> >>> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" >>> Eden is a part of the heap where new objects are allocated. >>> Basically, it appears that Pharo cannot create objects any more. >>> You can get information about gc and eden space here: >>> >>> Could you try to run your image in headless mode to see if it starts? >>> ex: >>> >>> I would try to start your image with a bigger size for the eden. >>> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >>> but it means you need an image that is started â¦ >>> >>> You can also set it as an argument to the VM: --eden <size>[mk] >>> >>> You could try with âeden 15207744 for example: >>> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image >> >> After copy the pharoLauncher entry with the error into Pharo7.0-64DTRDevErr entry >> >> i do this: >> >> /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image >> >> the shell report: >> >> pthread_setschedparam failed: Operation not permitted >> >> ***** This VM uses a separate heartbeat thread to update its internal clock >> and handle events. For best operation, this thread should run at a >> higher priority, however the VM was unable to change the priority. The >> effect is that heavily loaded systems may experience some latency >> issues. If this occurs, please create the appropriate configuration >> file in /etc/security/limits.d/ as shown below: >> >> cat <<END | sudo tee /etc/security/limits.d/pharo.conf >> * hard rtprio 2 >> * soft rtprio 2 >> END >> >> and report to the pharo mailing list whether this improves behaviour. >> >> You will need to log out and log back in for the limits to take effect. >> For more information please see >> ...........r3732#linux >> Errore di segmentazione (core dump creato) >> >> Any idea about it? > > So you have a segmentation fault. It means the image tries to access a memory address outside the memory range of its process. > using gdb on the core dump could help to have more clues: https://www.cprogramming.com/debugging/segfaults.html Tomorrow i investigate about it. > Do you also have a segmentation fault if you run the image without the eden parameter? No without eden parameter the system report the basic error >> The ***** message required some action ? > > this message is just a warning. If you want to avoid it, just execute this as root: >> cat <<END | sudo tee /etc/security/limits.d/pharo.conf >> * hard rtprio 2 >> * soft rtprio 2 >> END > >> P.S. I have to conclude that there is no solution? > > For now, it is too early to have a conclusion because we do not know what caused the crash. > As Eliot said, it could be useful to get the crash.dmp file and the PharoDebug.log file. The crash.dmp is not create. ( If i right do the command to create it : From pharoLauncher i launch the corrupt image some time, the shell report the issue, but don't create the crash.dmp file). For PharoDebug.log i'm not in office, I'll check tomorrow. Thanks, Dario

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Christophe Demarey

> Le 13 dÃ©c. 2018 Ã 17:31, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : > > Ciao, > >> Hi, >> >> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" >> Eden is a part of the heap where new objects are allocated. >> Basically, it appears that Pharo cannot create objects any more. >> You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… <https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…> >> >> Could you try to run your image in headless mode to see if it starts? >> ex: >> >> I would try to start your image with a bigger size for the eden. >> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >> but it means you need an image that is started â¦ >> >> You can also set it as an argument to the VM: --eden <size>[mk] >> >> You could try with âeden 15207744 for example: >> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image > > After copy the pharoLauncher entry with the error into Pharo7.0-64DTRDevErr entry > > i do this: > > /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image > > the shell report: > > pthread_setschedparam failed: Operation not permitted > > ***** This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the pharo mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > ...........r3732#linux > Errore di segmentazione (core dump creato) > > Any idea about it? So you have a segmentation fault. It means the image tries to access a memory address outside the memory range of its process. using gdb on the core dump could help to have more clues: https://www.cprogramming.com/debugging/segfaults.html <https://www.cprogramming.com/debugging/segfaults.html> Do you also have a segmentation fault if you run the image without the eden parameter? > The ***** message required some action ? this message is just a warning. If you want to avoid it, just execute this as root: > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > P.S. I have to conclude that there is no solution? For now, it is too early to have a conclusion because we do not know what caused the crash. As Eliot said, it could be useful to get the crash.dmp file and the PharoDebug.log file.

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > Hi All, > > On Dec 13, 2018, at 5:40 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > >> Hi, >> >> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" > > Then there should be a crash.dmp file that includes a stack trace. Iâm surprised the VM exists by this path; I would expect the system to retry the allocation with an old space allocation that should work. > > So, Dario, please keep a copy of your image and changes. And please email me the crash.dmp file. Create a clean one by deleting it first and then running the system until it fails and exits. Multiple exits append to the crash.dmp file so it can end up being quite large. OK. From pharoLauncher i launch the corrupt image some time, the shell report the issue, but don't create the crash.dmp file. Thanks, Dario > >> Eden is a part of the heap where new objects are allocated. >> Basically, it appears that Pharo cannot create objects any more. >> You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… >> >> Could you try to run your image in headless mode to see if it starts? >> ex: >> >> I would try to start your image with a bigger size for the eden. >> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >> but it means you need an image that is started â¦ >> >> You can also set it as an argument to the VM: --eden <size>[mk] >> >> You could try with âeden 15207744 for example: >> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image >> >> Regards, >> Christophe >> >> >>> Le 13 dÃ©c. 2018 Ã 09:25, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >>> >>> Ciao, >>> >>> i have a Ubuntu system >>> where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. >>> >>> I work with it for a month and all work fine. >>> >>> Now after a save the image the system begin unstabled. >>> >>> When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. >>> >>> The first time i can launch the same image from the PharoLauncher, >>> >>> but after a new image save ( the image go down ) i can't relaunch the image. >>> >>> When i do the launch the pharoLauch shell report: >>> >>> <errorePharo.txt> >>> >>> I have some important work in the image ( and i don't have a backup ) >>> >>> Some consideration? >>> >>> Thanks, >>> Dario >>> >>

Dec. 13, 2018

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

by Nicolas Cellier

Unfortunately you are right, thru system() call, there's no way to avoid the window popping up AFAIK. The library you are using, whatever it is, should invoke lower level API. The one from Levente (as indicated by Guile) souds OK from a rapid scan of source code. https://github.com/astares/Pharo-OS-Windows is not very far either with some little modifications, and is FFI based. so it's just a matter of picking code from here and there until libraries are powerful enough... IMO, there's no point in maintaining N different libraries, each with own flaw. I've always seen such fragmentation as a weakness (IOW it's a failure of core library to provide standard useful feature). I can understand that one alternative is FFI based, the other plugin based. But at the end, each should do the right thing or die. Le jeu. 13 dÃ©c. 2018 Ã 17:44, Christopher Fuhrman < christopher.fuhrman(a)inria.fr> a Ã©crit : > > On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> I think that Christopher and Peter are talking about ProcessWrapper and >> not OSProcess, >> > > Thanks to all who answered. I'm primarily interested in staying with LibC > because of its simplicity, robustness and its cross-platform compatibility > (although I have yet to run some of my code on Linux). From what I > understand after talking with Esteban, the ffi call to system() > in msvcrt.dll doesn't have any way to specify the Windows' option for the > CMD.EXE window, e.g., SW_HIDE. > > I have other ideas that maybe a future VM could implementation could > consider (if that's where the change would need to go), including > specifying a SETENV variable that is pharo-LibC-specific for turning on/off > the CMD.exe window. > > Christopher > > >> 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. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Eliot Miranda

Hi All, > On Dec 13, 2018, at 5:40 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi, > > The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" Then there should be a crash.dmp file that includes a stack trace. Iâm surprised the VM exists by this path; I would expect the system to retry the allocation with an old space allocation that should work. So, Dario, please keep a copy of your image and changes. And please email me the crash.dmp file. Create a clean one by deleting it first and then running the system until it fails and exits. Multiple exits append to the crash.dmp file so it can end up being quite large. > Eden is a part of the heap where new objects are allocated. > Basically, it appears that Pharo cannot create objects any more. > You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > > Could you try to run your image in headless mode to see if it starts? > ex: > > I would try to start your image with a bigger size for the eden. > ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. > but it means you need an image that is started â¦ > > You can also set it as an argument to the VM: --eden <size>[mk] > > You could try with âeden 15207744 for example: > ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image > > Regards, > Christophe > > >> Le 13 dÃ©c. 2018 Ã 09:25, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >> >> Ciao, >> >> i have a Ubuntu system >> where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. >> >> I work with it for a month and all work fine. >> >> Now after a save the image the system begin unstabled. >> >> When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. >> >> The first time i can launch the same image from the PharoLauncher, >> >> but after a new image save ( the image go down ) i can't relaunch the image. >> >> When i do the launch the pharoLauch shell report: >> >> <errorePharo.txt> >> >> I have some important work in the image ( and i don't have a backup ) >> >> Some consideration? >> >> Thanks, >> Dario >> >

Dec. 13, 2018

Re: [Pharo-dev] Application entrypoints

by Eliot Miranda

Hi Ben, On Wed, Dec 12, 2018 at 6:41 PM Ben Coman <btc(a)openinworld.com> wrote: > A question was asked on discord... "I know how to start the lights out > example, > and feed my objects test data with the testing framework, but how does one > start > something like ChineseCheckers? How does one find the entry point? > Is there a convention on naming a starting place?" > > I remember having similar thoughts when starting in Pharo. > > One convention I have seen is that amongst all the classes presumably > prefixed "CC" > one class would stand out being named for the application without the > prefix. > e.g. class "ChineseCheckers". That is only a narrow chance for a > namespace conflict, > the the risk still remains. > > I suggested another path would have a package tag "Application" > (i.e. "ChineseCheckers-Application") that contains a single class > which has an #open method on the class-side. > The tag "Application" sorts high up on the package-tags and is > self-descriptive. > But I've not seen that used before, so while I think its a good idea, its > not really a convention. > Conventions are only useful if they are broadly understood. > > So I'm wondering what other things people do to draw attention to their > application entry points. > I use a combination of class-side categories (instance creation, examples, api, etc) and class comments. e.g. in the class comment for StackInterpreterSimulator in VMMaker you'll find: | vm | vm := StackInterpreterSimulator newWithOptions: #(). vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'. vm setBreakSelector: #&. vm openAsMorph; run But the above is hard to find. I buy Doru's examples approach. Usually interesting objects are used in some kind of context and there may be a flow that the above illustrates, instantiation => initialization => use. All this is possible with examples, and examples have a pragma to identify them to tools. So I would push the examples direction. I guess the kernel of this approach is to create a method that creates and uses some object, and that is labelled with a specific pragma identifying it as an example. It can then serve as both a test and an example to users. > cheers -ben > _,,,^..^,,,_ best, Eliot

Dec. 13, 2018

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

by Christopher Fuhrman

On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > I think that Christopher and Peter are talking about ProcessWrapper and > not OSProcess, > Thanks to all who answered. I'm primarily interested in staying with LibC because of its simplicity, robustness and its cross-platform compatibility (although I have yet to run some of my code on Linux). From what I understand after talking with Esteban, the ffi call to system() in msvcrt.dll doesn't have any way to specify the Windows' option for the CMD.EXE window, e.g., SW_HIDE. I have other ideas that maybe a future VM could implementation could consider (if that's where the change would need to go), including specifying a SETENV variable that is pharo-LibC-specific for turning on/off the CMD.exe window. Christopher > 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. 13, 2018