May 2017 - Pharo-users - lists.pharo.org

HiDPI

by Steven R. Baker

Heya folks, I have a laptop with a 3K screen. Is it possible to tell Pharo to render everything at a double resolution or something? I feel like this ought to have been a solved problem already, sorry if it's really obvious and I just haven't found it. I use Debian if that matters; I suspect this just works out of the box on Macs. Cheers! -Steven

May 15, 2017

Vm crash

by Cyril Ferlicot D.

Hello, At Synectique a client reported us a problem that we cannot reproduce. The vm crash and the error displayed is: stack page bytes 4096 available headroom 3300 minimum unused headroom 1880 launchServer.sh: line 2: 34556 Aborted (core dumped) pharo-linux-vm/pharo Pharo.image serverDeployment The vm is the stable vm for Pharo 4. Does someone knows what can cause this kind of problem? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

May 15, 2017

Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding

by monty

For that kind of incremental parsing, you could also use XMLParserStAX, a pull-parser that parses a document as a stream of event objects you control with #next, #peek, and #atEnd. It also supports pull-DOM parsing with messages like #nextNode, #nextElement, and #nextElementNamed:, which return the next event object(s) as DOM subtrees (searchable with XPath). See the StAXParser class comment for an example. (The StAXHTMLParser class requires XMLParserHTML be installed to work.) > Sent: Friday, May 12, 2017 at 5:30 AM > From: PBKResearch <peter(a)pbkresearch.co.uk> > To: "'Any question about pharo is welcome'" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for utf-8 encoding > > With reference to Norbert's comment, there /may/ be an ambiguity about the > word 'header' in Udo's reply. It could refer to the http HEAD section, in > which case Norbert is of course right. It could also refer to the <head> > section of the html file, which is part of the content of the http response. > If it is the latter, this is similar to a question that Paul deBruicker > posted last November ("[Pharo-users] ZnClient GET, but just the content of > the <head> tag?"). I tried the method I devised for Paul's case on Udo's > problem website, and read the html header with no problem. Incidentally, the > header includes 'charset=iso-8859-1', which does not agree with Sven's > findings. > > In case it is of interest, I used XMLHTMLParser to read and parse the > header. Try the following in a Playground: > > par := XMLHTMLParser onURL: > 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns- > with-a-new-(borrowed)-distribution-method/a/d-id/1328723'. > par parseDocumentUntil: [|top|(top := par topNode) notNil and: [ top > isElement and:[ top isNamed: 'body']]]. > par parsingResult findElementNamed: 'head'. > > If you 'Do it and go', the full header appears. The way I get it to stop > after the header may not be quite correct, because it uses > XMLHTMLParser>>topNode, which is a private method. On the other hand, I > can't see how to make the stop condition for > XMLHTMLParser>>parseDocumentUntil: depend on the parsed results without > using a private method. > > Hope this is helpful > > Peter Kenny > > -----Original Message----- > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of > Norbert Hartl > Sent: 12 May 2017 08:04 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] [Zinc] ZnInvalidUTF8: Illegal leading byte for > utf-8 encoding > > Just to mention. If you are not interested in the content body you could do > a HEAD request instead of GET. > > Norbert > > > Am 11.05.2017 um 22:44 schrieb Udo Schneider > <udo.schneider(a)homeaddress.de>: > > > > Hi Sven, > > > > that's perfect. To be honest I don't care about the content - I'm just > parsing the header. And even if there is a wrong decoding in there... I can > live with that. > > > > Thank you very very much! For your help but also your stuff in general. > > > > CU, > > > > Udo > > > > > >> Am 11/05/17 um 22:35 schrieb Sven Van Caekenberghe: > >> Hi Udo, > >>> On 11 May 2017, at 21:37, Udo Schneider <udo.schneider(a)homeaddress.de> > wrote: > >>> > >>> All, > >>> > >>> I'm hitting an error where fetching web content fails. The website does > indeed use invalid characters. > >>> > >>> The easiest way to reproduce: > >>> > >>> ZnEasy get: > 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns- > with-a-new-(borrowed)-distribution-method/a/d-id/1328723' > >>> > >>> Is there any way to tell Zinc to simply ignore that error and to > continue? > >>> > >>> CU, > >>> > >>> Udo > >> That server/page has a mime-type text/plain with no explicit encoding > (charset) setting, so we have to guess. Like utf-8, pure latin1/iso88591 > does not work. The following does work, but you can't be sure everything > went well (beLenient takes some bytes as they are). > >> ZnDefaultCharacterEncoder > >> value: ZnCharacterEncoder latin1 beLenient > >> during: [ > >> ZnClient new > >> get: > 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns- > with-a-new-(borrowed)-distribution-method/a/d-id/1328723'; > >> yourself ]. > >> I added some API earlier today, so that the following should also work > (you need to load Zn #bleedingEdge first). > >> ZnClient new > >> defaultEncoder: ZnCharacterEncoder latin1 beLenient; > >> get: > 'http://www.darkreading.com/partner-perspectives/malwarebytes/locky-returns- > with-a-new-(borrowed)-distribution-method/a/d-id/1328723'; > >> yourself. > >> HTH, > >> Regards, > >> Sven > > > > > > > > > >

May 15, 2017

Re: [Pharo-users] SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)

by Julien Delplanque

Ok, I found a way to fix the problem. Simply, I needed to install the package lib32-libopenssl-1.0-compat which contains the library with "1.0.0" version. This should be added as dependency to the package in AUR. (the command: # yaourt -S lib32-libopenssl-1.0-compat) I can help for that if needed. Who manage the pharo-related packages for Arch? Julien On 09/05/17 11:24, Sven Van Caekenberghe wrote: > For Pharo 5, on the same machine: > > $ curl get.pharo.org/50+vm | bash > ... > > $ ./pharo --version > 5.0 #1 Wed May 4 11:54:28 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] > CoInterpreter VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux > > $ ./pharo Pharo.image printVersion > [version] 5.0 #50772 > $ ./pharo Pharo.image eval "ZnClient new get: 'https://pharo.org'" > 4149724864:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769: > ConnectionClosed: Connection closed while waiting for data. > ... > > This is normal, see https://pharo.fogbugz.com/f/cases/19864/Add-support-for-Server-Name-Indicat… which is integrated in 6 but not in 5. > > Note that the error is different from yours (no linking error, a runtime error). > > With other HTTPS sites, it still works on 5: > > audio359@audio359:~/pharo-dev/pharo5$ ./pharo Pharo.image eval "ZnClient new get: 'https://audio359.eu'" > ... > >> On 9 May 2017, at 09:08, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> Hello, >> >> I did the same thing as you and it works. >> >> When I do: >> >> ./pharo --version >> >> I get: >> >> 5.0-201705022326 Tue May 2 23:46:52 UTC 2017 gcc 4.6.3 [Production Spur ITHB VM] >> CoInterpreter VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2203 uuid: 12d4afae-8498-4e76-8efe-60eba6ef4db2 May 2 2017 >> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue May 2 16:26:41 2017 -0700 $ >> Plugins: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Linux testing-gce-7a7e75c9-f535-4934-bad2-d5fb6fd60cee 3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 i686 i686 i386 GNU/Linux >> plugin path: /tmp/pharo/pharo-vm/lib/pharo/5.0-201705022326 [default: /tmp/pharo/pharo-vm/lib/pharo/5.0-201705022326/] >> >> And when I check the version of the VM currently installed on my system: >> >> pharo-spur >> >> I get: >> >> 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM] >> CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >> StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016 >> https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <noreply(a)github.com> Jenkins build #594 >> Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linux >> plugin path: /usr/share/pharo/spur/ [default: /usr/share/pharo/spur/] >> >> So apparently those are not the same VMs. >> >> Nevertheless, when I open Pharo 6 image that I got using your curl command, it >> using the network works with both VM. >> >> So, I tried to load a Pharo 5 image with the VM: >> >> curl get.pharo.org/50+vm | bash >> >> And when I do: >> >> ./pharo Pharo.image eval "ZnClient new get: 'https://pharo.org'" >> >> I get: >> >> ioLoadModule(/tmp/pharo2/pharo-vm/libSqueakSSL.so): >> /usr/lib32/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /tmp/pharo2/pharo-vm/libSqueakSSL.so) >> ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?) >> [ :exception | ZdcPluginMissing signal ] in ZdcPluginSSLSession>>initialize in Block: [ :exception | ZdcPluginMissing signal ] >> BlockClosure>>cull: >> Context>>evaluateSignal: >> Context>>handleSignal: >> PrimitiveFailed(Exception)>>signal >> PrimitiveFailed class(SelectorException class)>>signalFor: >> ZdcPluginSSLSession(Object)>>primitiveFailed: >> ZdcPluginSSLSession(Object)>>primitiveFailed >> ZdcPluginSSLSession>>primitiveSSLCreate >> [ handle := self primitiveSSLCreate ] in ZdcPluginSSLSession>>initialize in Block: [ handle := self primitiveSSLCreate ] >> BlockClosure>>on:do: >> ZdcPluginSSLSession>>initialize >> ZdcPluginSSLSession class(Behavior)>>new >> ZdcSecureSocketStream>>sslSession >> ZdcSecureSocketStream>>connect >> ZnClient>>setupTLSTo: >> ZnClient>>newConnectionTo: >> ZnClient>>getConnectionAndExecute >> ZnClient>>executeWithRedirectsRemaining: >> [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... >> BlockClosure>>on:do: >> ZnClient>>executeWithRetriesRemaining: >> [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self executeWithRetriesRemaining: self numberOfRetries ] >> on: Error >> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... >> BlockClosure>>on:do: >> [ [ self executeWithRetriesRemaining: self numberOfRetries ] >> on: Error >> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self executeWithRetriesRemaining: self numberO...etc... >> [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ] >> [ p psValueAt: index put: anObject. >> aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ p psValueAt: index put: anObject.... >> BlockClosure>>ensure: >> ZnConnectionTimeout(DynamicVariable)>>value:during: >> ZnConnectionTimeout class(DynamicVariable class)>>value:during: >> >> So I guess it concerns Pharo 5 images/VM? >> >> Julien >> >> >> On 08/05/17 13:49, Sven Van Caekenberghe wrote: >>> Just to be sure, I tried from scratch: >>> >>> $ cat /etc/issue >>> Ubuntu 16.04.2 LTS >>> >>> $ uname -a >>> Linux audio359 3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> $ curl get.pharo.org/60+vm | bash >>> ... >>> >>> $ ./pharo Pharo.image printVersion >>> [version] 6.0 #60482 >>> >>> $ ./pharo Pharo.image eval "ZnClient new get: 'https://pharo.org'" >>> '<!DOCTYPE HTML> >>> <html> >>> <head> >>> ... >>> </html>' >>> >>> $ ldd pharo-vm/lib/pharo/5.0-201705022326/SqueakSSL.so >>> linux-gate.so.1 => (0xf773a000) >>> libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf751c000) >>> libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xf74b2000) >>> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf72fb000) >>> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf72f6000) >>> /lib/ld-linux.so.2 (0xf7718000) >>> >>> This is on a 64-bit Ubuntu with 32-bit libs installed (and that worked before). >>> >>> Something must be different in your case. >>> >>>> On 8 May 2017, at 13:36, Marc Hanisch via Pharo-users <pharo-users(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Marc Hanisch <marc.hanisch(a)googlemail.com> >>>> Subject: Re: [Pharo-users] SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?) >>>> Date: 8 May 2017 at 13:36:12 GMT+2 >>>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>>> >>>> >>>> Hello, >>>> I have the same problem on Ubuntu 16.04 and Fedora 25... >>>> >>>> Any hints? >>>> Marc >>>> >>>> >>>> Am 08.05.2017 13:18 schrieb "Julien Delplanque" <julien(a)tamere.eu>: >>>> Ok, I installed the missing library: >>>> >>>> yaourt -S lib32-openssl-1.0 >>>> >>>> now when I do: >>>> >>>> ldd /usr/share/pharo/vm/libSqueakSSL.so >>>> >>>> I get: >>>> >>>> /usr/share/pharo/vm/libSqueakSSL.so: /usr/lib32/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by /usr/share/pharo/vm/libSqueakSSL.so) >>>> linux-gate.so.1 (0xf77f1000) >>>> libssl.so.1.0.0 => /usr/lib32/libssl.so.1.0.0 (0xf7731000) >>>> libc.so.6 => /usr/lib32/libc.so.6 (0xf7571000) >>>> libcrypto.so.1.0.0 => /usr/lib32/libcrypto.so.1.0.0 (0xf7360000) >>>> /usr/lib/ld-linux.so.2 (0x565de000) >>>> libdl.so.2 => /usr/lib32/libdl.so.2 (0xf735b000) >>>> >>>> So it is still not working, I still get the exception in Pharo. :-( >>>> >>>> Julien >>>> >>>> >> >

May 15, 2017

Re: [Pharo-users] Windows equivalent of kill -s SIGUSR1?

by Alistair Grant

Hi Subbu, On Mon, May 15, 2017 at 11:16:45AM +0530, K K Subbu wrote: > On Monday 15 May 2017 02:47 AM, Alistair Grant wrote: > >The subject pretty much says it all: Is there an equivalent on Windows > >to the linux > > > >kill -s SIGUSR1 <pid> > > > >that gets the VM to dump its current status? > > signals is unix-specific IPC. On Windows, you should be able to "create dump > file" from right-click menu on Task Manager's process list (if you have the > perms, of course!). > > If you do a lot of system work on windows, sysinternals suite could be very > useful. It has many utilities for advanced operations (Procdump?) on > processes and files. It looks like "dump" was a poor choice of words, as I expanded on in my reply to Henrik, it's about requesting the VM to print out its internal information. The VM continues to function "normally" after the request has been processed. Thanks, Alistair

May 15, 2017

Re: [Pharo-users] Windows equivalent of kill -s SIGUSR1?

by K K Subbu

On Monday 15 May 2017 02:47 AM, Alistair Grant wrote: > The subject pretty much says it all: Is there an equivalent on Windows > to the linux > > kill -s SIGUSR1 <pid> > > that gets the VM to dump its current status? signals is unix-specific IPC. On Windows, you should be able to "create dump file" from right-click menu on Task Manager's process list (if you have the perms, of course!). If you do a lot of system work on windows, sysinternals suite could be very useful. It has many utilities for advanced operations (Procdump?) on processes and files. HTH .. Subbu

May 15, 2017

Re: [Pharo-users] Windows equivalent of kill -s SIGUSR1?

by Alistair Grant

Hi Henrik, On Sun, May 14, 2017 at 09:58:12PM +0000, Henrik Nergaard wrote: > > Windows do not have Unix-style signals such as SIGUSR1. > > To kill a process you can use Windows PowerShell: > > $ Stop-Process -Name Pharo > > Or by pid: > > $ Get-Process -Name Pharo > > $ Stop-Process -Id 42 Thanks for your reply. The kill command on Unix is somewhat misnamed, it actually just sends one of a number of signals to the process. For some of those signals, it is up to the process to decide how it will respond. For the USR1 signal, the VM responds by printing out information about its internal state, including: - version information - C stack backtrace & registers - All Smalltalk process stacks - Most recent primitives What I'm hoping is that the same thing can be done on Windows. My understanding is that stop-process can only be used for terminating a process. Cheers, Alistair > From: Alistair Grant > Sent: 14 May 2017 23:18 > To: pharo-users(a)lists.pharo.org > Subject: [Pharo-users] Windows equivalent of kill -s SIGUSR1? > > > > Hi All, > > The subject pretty much says it all: Is there an equivalent on Windows > to the linux > > kill -s SIGUSR1 <pid> > > that gets the VM to dump its current status? > > Thanks, > Alistair

May 15, 2017

Re: [Pharo-users] PetitParser installation fails in Pharo 5.0

by Andreas Sunardi

It isn't glibc issue. Perhaps my wording makes it unclear. When I said 'linux' or 'linux with old glibc', I was referring to the image versions that come with those download options. I wasn't referring to glibc itself. -- Andreas Sunardi On Sun, May 14, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I do not really see why loading a package would be related to old glibc > but may be :) > With software.... who knows. > Now what is important for you is that you always tries to load and produce > configurations. > > Stef > > On Sun, May 14, 2017 at 2:03 AM, Andreas Sunardi <a.sunardi(a)gmail.com> > wrote: > >> Hi Stephane, >> >> I shall read that Metacello chapter. I had considered this case closed >> until you replied again. I took another peek and I think I found the root >> cause. And for the sake of those who stumble on this email thread, I should >> clarify this. >> >> This is probably related to my old email thread about running Pharo 5.0 >> on linux with old glibc, which resulted in Pharo5.0-linux-oldLibC download >> to work properly. >> http://lists.pharo.org/pipermail/pharo-users_lists.pharo. >> org/2016-October/028431.html >> >> Following your solution, after installing PetitParser from Catalog >> Browser in Windows version, I noticed the ConfigurationOfPetitParser >> version is TudorGirba.80, the version I had problem in linux. I then >> wondered why it didn't work on my linux with old glibc versions. Here's >> what I found >> >> Download and version (SystemVersion current imageVersionString): >> centos Pharo-5.0-50761- >> linux Pharo-5.0-50772- >> linux-oldLibC *Pharo-6.0-60257-* >> >> Pharo5.0-linux-oldLibC has image for Pharo 6.0. This is the one I use >> where PetitParser installation failed. >> >> Using Catalog Browser, or Gofer instruction from smalltalkhub, for #load >> and #loadDevelopment versions, PetitParser installation works fine for >> images that come from linux and centos versions, but not from >> linux-oldLibC. >> >> So, I believe that is the problem. I'm not sure what's the right >> solution, but I think I can stay in this image and use TudorGirba.77 >> version or I can try using image from linux version. >> >> Thanks again. If you hadn't replied about Metacello, I'd have never taken >> another look and found this. >> >> -- >> Andreas Sunardi >> >> On Sat, May 13, 2017 at 12:45 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> You should read the beginning of the chapter on metacello. >>> Metacello is a map >>> Monticello element of the map >>> >>> You load elements by asking the map. >>> >>> Stef >>> >>> On Sat, May 13, 2017 at 3:43 AM, Andreas Sunardi <a.sunardi(a)gmail.com> >>> wrote: >>> >>>> Hi Stephane, >>>> >>>> Indeed, PetitParser installation from Catalog Browser works just fine! >>>> Thank you very much. >>>> >>>> I used Monticello Browser before, but not Catalog Browser. I didn't >>>> know this is the preferred method to install package. I don't think >>>> DeepIntoPharo mentions about Catalog Browser, but maybe my version is >>>> outdated. >>>> >>>> Thanks again, Stephane. >>>> >>>> -- >>>> Andreas Sunardi >>>> >>>> On Fri, May 12, 2017 at 12:48 PM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> Sorry I meant the catalogBrowser. >>>>> Using the catalogBrowser on a given version of Pharo you should access >>>>> the configuration for this version (if people updated it correctly). >>>>> Our plan is to make sure that such configurations are validated. >>>>> Stef >>>>> >>>>> On Fri, May 12, 2017 at 9:47 PM, Stephane Ducasse < >>>>> stepharo.self(a)gmail.com> wrote: >>>>> >>>>>> Hi andreas >>>>>> >>>>>> Normally you should be able to load a package using the >>>>>> ConfigurationBrowser and the configuration (now I do not know the one of >>>>>> PetitParser) >>>>>> should take care of the pharo version for you. >>>>>> >>>>>> stef >>>>>> >>>>>> >>>>>> On Fri, May 12, 2017 at 7:06 PM, Andreas Sunardi <a.sunardi(a)gmail.com >>>>>> > wrote: >>>>>> >>>>>>> Following DeepIntoPharo, I tried to install PetitParser into my >>>>>>> Pharo 5.0 image (I noticed PetitParser installation problem email in >>>>>>> March). It failed with the message WinPlatform class was undefined. I went >>>>>>> to Moose's PetitParser site in smalltalkhub and followed the instruction >>>>>>> there, and this also failed. >>>>>>> >>>>>>> Out of frustration, I downloaded Moose 6.0 and thought I'd start >>>>>>> from Moose image instead. But then I noticed Moose's PetitParser package >>>>>>> has ConfigurationOfPetitParser from version TudorGirba.77 and the >>>>>>> instruction I followed was trying to install it using version >>>>>>> TudorGirba.80. Back to my Pharo 5 image, I unload/remove >>>>>>> ConfigurationOfPetitParser and load version TudorGirba.77. And this works! >>>>>>> >>>>>>> But this way to solve PetitParser installation problem seems wrong. >>>>>>> I figure if this could very well happen with other packages too. What is >>>>>>> the right way to find package version that works with my image/pharo >>>>>>> version? Or is this an issue with PetitParser package itself and should I >>>>>>> ask/report this to Moose team? >>>>>>> >>>>>>> -- >>>>>>> Andreas Sunardi >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

May 15, 2017

Re: [Pharo-users] Windows equivalent of kill -s SIGUSR1?

by Henrik Nergaard

Windows do not have Unix-style signals such as SIGUSR1. To kill a process you can use Windows PowerShell: $ Stop-Process -Name Pharo Or by pid: $ Get-Process -Name Pharo $ Stop-Process -Id 42 Best regards, Henrik Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Alistair Grant<mailto:akgrant0710@gmail.com> Sent: 14 May 2017 23:18 To: pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org> Subject: [Pharo-users] Windows equivalent of kill -s SIGUSR1? Hi All, The subject pretty much says it all: Is there an equivalent on Windows to the linux kill -s SIGUSR1 <pid> that gets the VM to dump its current status? Thanks, Alistair

May 14, 2017

Windows equivalent of kill -s SIGUSR1?

by Alistair Grant

Hi All, The subject pretty much says it all: Is there an equivalent on Windows to the linux kill -s SIGUSR1 <pid> that gets the VM to dump its current status? Thanks, Alistair

May 14, 2017