[Pharo-users] Re: aio event forwarding not supported

[David T. Lewis]

Hi David,

I do not think I can help, maybe someone with Big Sur can take a look?

I am on Linux. I did a fresh download of Pharo 8 and loaded OSProcess,
and I cannot reproduce the problem on my system.

Dave


On Fri, Feb 04, 2022 at 03:54:57PM +, Davide Varvello via Pharo-users wrote:
>  Hi David,I don't think is an issue of warning, even if I apply your patch I 
> have the same error, see: https://imgur.com/a/pYcLLWx
> 
> 
> 
> To reproduce the bug:??Be on ??Big Sur 11.6.3 (20G415) 
> https://support.apple.com/en-us/HT213055Download Pharo 8: curl 
> https://get.pharo.org/64/80+vm|bash
> Open the image and evaluate ina playground:Metacello new ?? 
> configuration: 'OSProcess'; ?? repository: 
> 'http://www.squeaksource.com/MetacelloRepository';?? ?? load .
> 
> and then
> (PipeableOSProcess command: 'ps') ??output.
> 
> The bug will show itself
> CheersDavide
> On Friday, February 4, 2022, 04:39:28 PM GMT+1, David T. Lewis 
>  wrote:  
>  
>  Hi Davide,
> 
> Actually the warning has been removed in newer versions of OSProcess.
> I do not have time to do an update for Pharo now, but in the mean time
> you can apply this change in your image to remove the notifier:
> 
> AioEventHandler>>initializeForExceptions: exceptionEventFlag readEvents: 
> readEventFlag writeEvents: writeEventFlag
> ?? semaphore := Semaphore new.
> ?? semaIndex := Smalltalk registerExternalObject: semaphore.
> ?? (AioPluginPresent = true) ifTrue: [
> ?? ?? ([self aioEnable: self descriptor forSemaphore: self semaIndex 
> externalObject: true]
> ?? ?? ?? on: Warning
> ?? ?? ?? do: [:e |
> ?? ?? ?? ?? self close. "unregister the semaphore"
> ?? ?? ?? ?? OSProcess trace: e messageText asString. nil])
> ?? ?? ?? ifNotNil:
> ?? ?? ?? ?? [handlerProc := self
> ?? ?? ?? ?? ?? handleExceptions: exceptionEventFlag
> ?? ?? ?? ?? ?? readEvents: readEventFlag
> ?? ?? ?? ?? ?? writeEvents: writeEventFlag]]
> 
> 
> HTH,
> Dave
> 
> 
> 
> On Fri, Feb 04, 2022 at 03:05:57PM +, Davide Varvello wrote:
> >?? Hi David,That's weird because if the AioPlugin is not present in my 
> >VM,??PipeableOSProcess shouldn't have worked till this morning... when I 
> >upgraded my mac :-)
> > The warning is not skippable, it stops me at:??MessageNotUnderstood: 
> > IRJump>> #nextBytecodeOffsetAfterJumpCheersDavide
> > 
> >?? ?? On Friday, February 4, 2022, 03:54:59 PM GMT+1, David T. Lewis 
> > wrote:?? 
> >?? 
> >?? On Fri, Feb 04, 2022 at 01:46:46PM +, Davide Varvello via Pharo-users 
> >wrote:
> > > Hi guys,
> > > Suddenly evaluating a simple: (PipeableOSProcess command: 'ps') output, 
> > > or any other PipeableOSProcess command, Pharo gives me: "aio event 
> > > forwarding not supported".
> > > I guess it is something related to the latest update of the OS, 
> > > specifically Big Sur 11.6.3 (20G415) 
> > > https://support.apple.com/en-us/HT213055I'm on a Mac, of course, Pharo 
> > > 8.0.0, Build information: 
> > > Pharo-8.0.0+build.1128.sha.9f6475d88dda7d83acdeeda794df35d304cf620d (64 
> > > Bit)
> > > Can you help me, please?CheersDavide
> > 
> > Hi Davide,
> > 
> > The warning message indicates that the AioPlugin is not present
> > in your VM. I do not know the reason for that, although your
> > PipeableOSProcess should still work if you proceed through the
> > warning.
> > 
> > Dave
> > 
> >?? 
>   

[Pharo-users] Re: aio event forwarding not supported

[David T. Lewis]

Hi Davide,

Actually the warning has been removed in newer versions of OSProcess.
I do not have time to do an update for Pharo now, but in the mean time
you can apply this change in your image to remove the notifier:

AioEventHandler>>initializeForExceptions: exceptionEventFlag readEvents: 
readEventFlag writeEvents: writeEventFlag
semaphore := Semaphore new.
semaIndex := Smalltalk registerExternalObject: semaphore.
(AioPluginPresent = true) ifTrue: [
([self aioEnable: self descriptor forSemaphore: self semaIndex 
externalObject: true]
on: Warning
do: [:e |
self close. "unregister the semaphore"
OSProcess trace: e messageText asString. nil])
ifNotNil:
[handlerProc := self
handleExceptions: exceptionEventFlag
readEvents: readEventFlag
writeEvents: writeEventFlag]]


HTH,
Dave



On Fri, Feb 04, 2022 at 03:05:57PM +, Davide Varvello wrote:
>  Hi David,That's weird because if the AioPlugin is not present in my 
> VM,??PipeableOSProcess shouldn't have worked till this morning... when I 
> upgraded my mac :-)
> The warning is not skippable, it stops me at:??MessageNotUnderstood: IRJump>> 
> #nextBytecodeOffsetAfterJumpCheersDavide
> 
> On Friday, February 4, 2022, 03:54:59 PM GMT+1, David T. Lewis 
>  wrote:  
>  
>  On Fri, Feb 04, 2022 at 01:46:46PM +, Davide Varvello via Pharo-users 
> wrote:
> > Hi guys,
> > Suddenly evaluating a simple: (PipeableOSProcess command: 'ps') output, or 
> > any other PipeableOSProcess command, Pharo gives me: "aio event forwarding 
> > not supported".
> > I guess it is something related to the latest update of the OS, 
> > specifically Big Sur 11.6.3 (20G415) 
> > https://support.apple.com/en-us/HT213055I'm on a Mac, of course, Pharo 
> > 8.0.0, Build information: 
> > Pharo-8.0.0+build.1128.sha.9f6475d88dda7d83acdeeda794df35d304cf620d (64 Bit)
> > Can you help me, please?CheersDavide
> 
> Hi Davide,
> 
> The warning message indicates that the AioPlugin is not present
> in your VM. I do not know the reason for that, although your
> PipeableOSProcess should still work if you proceed through the
> warning.
> 
> Dave
> 
>   

[Pharo-users] Re: aio event forwarding not supported

[David T. Lewis]

On Fri, Feb 04, 2022 at 01:46:46PM +, Davide Varvello via Pharo-users wrote:
> Hi guys,
> Suddenly evaluating a simple: (PipeableOSProcess command: 'ps') output, or 
> any other PipeableOSProcess command, Pharo gives me: "aio event forwarding 
> not supported".
> I guess it is something related to the latest update of the OS, specifically 
> Big Sur 11.6.3 (20G415) https://support.apple.com/en-us/HT213055I'm on a Mac, 
> of course, Pharo 8.0.0, Build information: 
> Pharo-8.0.0+build.1128.sha.9f6475d88dda7d83acdeeda794df35d304cf620d (64 Bit)
> Can you help me, please?CheersDavide

Hi Davide,

The warning message indicates that the AioPlugin is not present
in your VM. I do not know the reason for that, although your
PipeableOSProcess should still work if you proceed through the
warning.

Dave

[Pharo-users] Re: Access to old image / source

[David T. Lewis]

On Mon, Nov 08, 2021 at 07:31:12PM +1100, Jupiter Jones wrote:
> I have an old image I???d like to recover some code from.
> 
> When I try to launch in Pharo 2 (from memory it was written in Pharo 2) I get 
> this error:
> 
> This interpreter (vers. 6505) cannot read image file (vers. 6502).
> 
> It looks close :)
> 
> How do I go about finding a VM that will open that image?
> 
> Thanks in advance.

Hi Jupiter,

You probably can run your old image in a web browser at http://try.squeak.org/
Just drag and drop the image, changes and source files onto the web page.

HTH,
Dave

Re: [Pharo-users] Bit Manipulation Challenge

[David T. Lewis]

On Tue, Jul 21, 2020 at 02:17:59AM +0800, Ben Coman wrote:
> On Mon, 20 Jul 2020 at 23:19, Sean P. DeNigris  wrote:
> >
> > I want to take an IP address routing prefix in CIDR [1] notation (i.e. the 
> > 24
> > in "192.168.100.14/24") and convert it into subnet form (i.e.
> > 255.255.255.0). I came up with 4 ways to do that (see below), but none stand
> > out as best (although #3 and #4 seem a bit more straightforward as they
> > avoid the `max` temp).
> >
> > How would you go about it?
> >
> > Here are the ways I came up with:
> > cidr := 24.
> > shift := 32 - cidr.
> > max := #[ 255 255 255 255 ] asInteger.
> > "1." ((max bitShift: shift negated) bitShift: shift) asByteArray.
> > "2." (max bitClear: (2 raisedTo: shift) - 1) asByteArray.
> > "3." ((2 raisedTo: shift) - 1) bitInvert32 asByteArray.
> > "4." (((2 raisedTo: cidr) - 1) bitShift: shift) asByteArray
> 
> To me the most complicated ones have the "subtract 1" - it makes it
> harder to reason about.  I'd also guess "3" and "4" are slowest.
> 
> "1." can be simplified by hardcoding max
> 5. (4294967295 bitShift: shift negated) bitShift: shift) asByteArray
> 
> Additional alternative...
> 6. ((4294967295 bitShift: shift) rem: 4294967296) asByteArray
> 
> And why not low-brow...
> 7. CIDRLookup at: cidr.
> 
> cheers -ben

This also seems to work for IPV4:

  (max << shift) asByteArray last: 4

Dave

Re: [Pharo-users] Do we have a simple markdown parser?

[David T. Lewis]

On Fri, Mar 27, 2020 at 08:35:47AM -0700, Ramon Leon wrote:
> On 2020-03-26 3:24 p.m., Eric Gade wrote:
> >Hi Ram??n,
> >
> >I have a couple of questions. If you are using OSProcess in Pharo 8
> 
> I'm not, I don't try and keep up with the latest stuff, too much churn.  
> But I'd imagine the latest must still be able to pipe out to a command even 
> if the API changed a bit.
> 

For Pharo 7, you may want to use these:

https://github.com/dtlewis290/OSProcess-Tonel
https://github.com/dtlewis290/CommandShell-Tonel

I have not tried Pharo 8, so I cannot say if it works there.

Dave

> > but the new ZnStreams in P7/P8 DNU on #isOssPipe and StandardFileStream 
> > (for which OSSubprocess was designed, evidently) is being deprecated.
> 
> And this is why it's not worth riding the bleeding edge.  Go back and find 
> a stable older version you like and stick with it. Let others get all cut 
> up playing with unstable new stuff.
> 
> -- 
> Ram??n Le??n
> 

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

[David T. Lewis]

On Fri, Jan 10, 2020 at 10:52:51AM +0100, jtuc...@objektfabrik.de wrote:
> 
> I wanted to stay out of this thread, because it leads nowhere. But now 
> that I've typed all this, I will push the send button and regret it in a 
> few minutes...

Joachim,

Thanks for pushing the send button.

Dave

Re: [Pharo-users] Code overview - or maybe not

[David T. Lewis]

On Thu, Dec 19, 2019 at 09:57:43PM +0100, Trygve Reenskaug wrote:
> Such a tool has existed for a long time, it's called /Squeak Reverse 
> Engineering /(/SRE/). It's very useful for exploring execution stacks, 
> objects, and object structures. It goes across different kinds of 
> objects. It only works in Squeak 3.10.2.
> User manual at
> http://folk.uio.no/trygver/themes/SRE/BabySRE.pdf
> Latest version of the SRE programs in this image
> http://dx.doi.org/10.17632/5xxgzv7fsp.1


I just downloaded this image from http://dx.doi.org/10.17632/5xxgzv7fsp.1
and it is working fine on my Linux laptop. It does require a suitable VM
(I compile my own). Very interesting stuff, thanks.

Dave

> 
> Examples. (Top line/[OOP]object name if any/. Bottom line /://Object's 
> clas//s name/).
> 
> 
> 
> 
> The new object inspector with state and behavior.
> 
> 
> 
> The new /Transcript //show:xx/ with the stack.
> 
> 
> 

Re: [Pharo-users] OSProcess and CommandShell available on GitHub for Pharo users

[David T. Lewis]

Hi Sean,

On Mon, Oct 14, 2019 at 08:16:17AM -0500, Sean P. DeNigris wrote:
> David T. Lewis wrote
> > Alistair Grant and I, with the support of Feenk, have made GitHub
> > repositories
> > for OSProcess and CommandShell
> 
> Thank you to all involved!
> 
> 
> David T. Lewis wrote
> > my own development work remains on squeaksource so I prefer
> > contributions there anyway
> 
> It might be good to add that disclaimer and the location of the canonical
> repo to the GH README. Also, does anyone know whether, after loading from
> GH, one can make enhancements and then simply save to an MCZ repo?
> 

To be honest, I'm not really sure how this should work. My sense is that
it is better for Pharo users to use the Pharo tools, and save changes in
git. In the case of OSProcess and CommandShell, I can harvest any changes
manually, and for me it is probably easiest to just do it that way.

Dave

Re: [Pharo-users] OSProcess and CommandShell available on GitHub for Pharo users

[David T. Lewis]

On Mon, Oct 14, 2019 at 11:01:13AM -0500, Sean P. DeNigris wrote:
> David T. Lewis wrote
> > they can now be loading in Pharo...
> 
> In Pharo 7.0.4, the following chugged for about an hour cycling back and
> forth between OSP and Command Shell without completing:
>   baseline: 'OSProcess' with: [
>   spec
>   repository: 
> 'github://dtlewis290/OSProcess-Tonel';
>   loads: #(#'Core with Output') ]
> 

Hi Sean,

Alistair put together the two load scripts, and they worked when I
last checked them. These are on the README.md descriptions as:

  Metacello new
repository: 'github://dtlewis290/OSProcess-Tonel/src';
baseline: 'OSProcess';
load.

  Metacello new
repository: 'github://dtlewis290/CommandShell-Tonel/src';
baseline: 'CommandShell';
load.

I am not familiar with the baseline approach, so maybe someone else
can give a pointer?

> 
> I wonder if it's related to the old circular dependency problem we had which
> IIRC was resolved with "Pipeability"...
> 

Possibly so. I think this may have been something to do with an earlier
OSProcess load specification that included part of the CommandShell package.

Dave

Re: [Pharo-users] Set >> collect:thenDo:

[David T. Lewis]

On Mon, Sep 09, 2019 at 05:46:48PM +1200, Richard O'Keefe wrote:
> 
> (3) Oddly enough, the reason that #collect:thenDo: exists in my
> library is that I copied it from Squeak, at a time when it had
> the same definition as Pharo and ST/X.  Had I known of the change
> in Squeak I would have bitterly opposed it.  The comment in the
> current Squeak code, that it is for readability, is 100% the
> reverse of the truth.  Using the version with parentheses is WAY
> clearer than using the portmanteau method.  Sigh.  I see they
> broke #collect:thenSelect: in the same way.
>

In Squeak, collect:thenDo: is implemented only in Collection.
The method stamp is dgd 9/13/2004 23:42, which hardly qualifies as
a recent change. And the method stamp for collect:thenSelect: is
sma 5/12/2000.

Dave
 

Re: [Pharo-users] Symbol equality method #= - weird condition in the Pharo sourcecode

[David T. Lewis]

On Fri, Mar 01, 2019 at 05:18:27PM +0100, Sven Van Caekenberghe wrote:
> 
> 
> > On 1 Mar 2019, at 17:08, Petr Fischer via Pharo-users 
> >  wrote:
> > 
> > 
> > From: Petr Fischer 
> > Subject: Symbol equality method #= - weird condition in the Pharo sourcecode
> > Date: 1 March 2019 at 17:08:03 GMT+1
> > To: pharo-users@lists.pharo.org
> > 
> > 
> > Hello, this is Symbol equality method in Pharo:
> > 
> > 1: = aSymbol
> > 2:  "Compare the receiver and aSymbol." 
> > 3:  self == aSymbol ifTrue: [^ true].
> > 4:  self class == aSymbol class ifTrue: [^ false].
> > 5:  "Use String comparison otherwise"
> > 6:  ^ super = aSymbol
> > 
> > Look at line 4 - what does it mean? That's wrong, isn't it?
> > 
> > Typically, every symbol comparisons end up in line 3, but if you do some 
> > work with forward proxies for example, condition on line 3 is "false" and 
> > then weird things on line 4 happens.
> > 
> > If line 4 and further are correct, can someone explain a little?
> > 
> > Thanks! pf
> 
> Yes, that looks weird. Line 4 should probably be removed, unless I am missing 
> something.

It is wrong in a Spur image, because we now have subclasses of Symbol.
But removing line 4 is not the right solution. See Nicolas' implementation
in Squeak:

Symbol>>= aSymbol
"Compare the receiver and aSymbol." 
self == aSymbol ifTrue: [^ true].
aSymbol isSymbol ifTrue: [^ false].
"Use String comparison otherwise"
^ super = aSymbol

Dave

> 
> Symbols are by definition always #== so in that sense, #= should not even be 
> implemented (as #= on Object is defined as #==), but since its direct super 
> class String already overwrote #=, it has to follow.
> 
> The super call in line 6 is what allows Symbols and String to be compared.
> 
> I would say line 4 is a kind of sanity check, but probably not needed.
> 
> 

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

[David T. Lewis]

On Tue, Feb 19, 2019 at 11:37:38AM +0100, Albrecht Baur via Pharo-users wrote:
> From: Albrecht Baur 
> Subject: OSProcess / OSSubprocess / LibC uniqueInstance
> To: pharo-users@lists.pharo.org
> Date: Tue, 19 Feb 2019 11:37:38 +0100
> 
> I need to execute OS commands from within a x64 pharo 7.01 image on 
> centos7 (for example: 'zip -r 123.zip zipme/').
> 
> I found these 3 tools: OSProcess, OSSubprocess, LibC uniqueInstance
> 
> But I did not find any docu on which one to use for which use case.
> 
>  * OSProcess is in the catalog browser but fails loading because of
>ByteArray>>ifNotNilDo:
>-> So OSProcess is not to be used with p7 ?

Hi Albrecht,

I am sorry that I cannot check it right now, but it may be that
ConfigurationOfOSProcess needs to be updated. The #ifNotNilDo: problem
was fixed by Thierry Goubier in July 2017, so perhaps you are using
an out of date version.

Hopefully someone else can give you a better answer, otherwise I will
try to follow up in a day or two.

Dave



> 
>  * OSSubprocess loads via catalog browser and the following snippet
>works (even though 64 bit):
> 
> OSSUnixSubprocess new
> ?? command: 'zip';
> ?? arguments: #('-r' '123.zip' 'zipme');
> ?? redirectStdout;
> ?? runAndWaitOnExitDo: [ :process :outString?? |
> ?? ?? outString inspect
> ?? ]
> 
> So is it ok to use OSSubprocess with 64 bit even though documented as 32 
> bit only ? (here: 
> https://github.com/pharo-contributions/OSSubprocess#installation)
> 
>  * LibC uniqueInstance system: 'zip -r 123.zip zipme/'
>... works, but I don't know if its the right tool for this.
> 
> Is there somewhere more info on which tool to use for which use case ?
> 
> Thanks in advance!
> 
> Albrecht
> 
> PS.: I need to use zip as os process only because of this issue: 
> https://github.com/pharo-project/pharo/issues/2584
> 

Re: [Pharo-users] Pharo 7 file streams guideline

[David T. Lewis]

On Wed, Jul 25, 2018 at 02:20:30PM +0200, Damien Pollet wrote:
> On Wed, 25 Jul 2018 at 13:48, Sven Van Caekenberghe  wrote:
> 
> > > On 25 Jul 2018, at 13:39, Damien Pollet 
> > wrote:
> > > Related issue: command line arguments come from VM system attributes as
> > ByteStrings??? and thus interpreted as iso-8859-1, which is incorrect in 
> > most
> > cases nowadays, even though it seems to work as long as you only use ASCII.
> > Decoding them is easy enough, but it requires two copies (asByteString
> > utf8Decoded)
> >
> > Yes this is a really big issue. Anything coming in as command line arg or
> > environment variable (or clipboard) is in a basically unknown OS determined
> > encoding. I would assume/hope the UTF-8 is the sensible default today, but
> > apparently not. And it is hard to find a cross platform solution.
> >
> 
> My point here was that it would make more sense for those to be passed into
> the image as ByteArrays, revealing the fact that their encoding is unknown.
> Currently the bytes are correct, but since they've been shoved into
> ByteStrings by the VM, the characters will be wrong unless your system
> happens to be using Latin 1.

That sounds right to me.

Having said that, there should be no need to change the VM interface to do
this. A ByteString is by definition an array of 8 bit wide characters, and
conversion between ByteString and ByteArray is trivial. Any necessary changes
can be done without touching the VM.

Dave

> 
> I suppose we can either have a setting for decoding (since it's pretty much
> arbitrary), or heuristics like checking LC_CTYPE or whatever. Pablo
> mentioned the Locale class, but it doesn't seem to detect anything correct
> from the environment.

Re: [Pharo-users] Pharo 7 file streams guideline

[David T. Lewis]

On Mon, Jul 23, 2018 at 07:38:16PM +0100, Denis Kudriashov wrote:
> Hi.
> 
> I wonder does not stdout and stdin are always about text input/output?

No. Consider the case of reading and writing serialized objects on stdin
and stdout, possibly between two images sending serialized objects to one
another.


> I never saw examples when somebody explicitly write raw bytes into these
> streams.

http://wiki.squeak.org/squeak/6176

I have not checked recently, but it should still work on Pharo with Fuel
serialization.

> 
> If I am right then it is better to introduce binaryStdout and binaryStdin
> messages. And make stdout and stdin use most common encoding by default.
> How it is done in Java?
> 

You are probably right that this is the best default, since it would be the
most common case.

Dave


> 
> 2018-07-23 19:19 GMT+01:00 Alistair Grant :
> 
> > Hi Pavel & Sven,
> >
> > Thanks for writing this, it is a great quick reference.
> >
> >
> > On Mon, 23 Jul 2018 at 12:08, Sven Van Caekenberghe  wrote:
> > >
> > >
> > >
> > > > On 23 Jul 2018, at 11:13, Ben Coman  wrote:
> > > >
> > > > I like all the new code examples until  "Write a UTF-8 text to STDOUT"
> > > > and I wonder "Stdio stdout  writeStreamDo: [ :stream | stream
> > > > nextPutAll: 'a ??? b' ]"  would better fit the pattern of the other new
> > > > code.
> > > > (presuming "Stdio stdout" returns a FileReference, oherwise maybe
> > > > "Stdio stdoutRef" or "Stdio stdout asFileReference")
> > >
> > > Stdio stdout and friends just return a binary stream, hence they need
> > wrapping for encoding.
> > >
> > > Maybe
> > >
> > >   Stdio stdoutAsText
> > >
> > > might be an idea, but this is so uncommon that I am not sure this is a
> > good idea.
> >
> > I've written this code enough times that I'd like to see it included. :-)
> >
> > Maybe
> >
> > Stdout utf8Stdout
> >
> > (following the pattern of ByteArray>>utf8Decoded, String>>utf8Encoded)
> >
> > ?
> >
> > Thanks again,
> > Alistair
> >
> >

Re: [Pharo-users] [Ann] OSSubprocess 1.0.0

[David T. Lewis]

Hi Mariano, hi Thierry,

I cannot follow up for a few days but I like Mariano's proposal and I
think that it will work. Maybe move the child reaper process to a small
OSChildWatcher class and have interested clients (OSP, OSSP, others)
subscribe to update notifications.

Dave

> Hi Thierry. Excellent question. For OSSubprocess this is not an issue
> because I look up by pid in my list of forked children... So if not found
> I
> do nothing... At least that's what I remember (away from my machine now).
> So at worst it would be a performance problem when both loaded.
>
> As for osprocess I don't recall if this would be a problem but I imagine
> it
> won't. Maybe David can tell.
>
>
> On Wed, May 23, 2018, 5:31 PM Thierry Goubier <thierry.goub...@gmail.com>
> wrote:
>
>> Hi Mariano,
>>
>> 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck
>> <marianop...@gmail.com>:
>> >
>> >
>> > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris
>> <s...@clipperadams.com>
>> > wrote:
>> >>
>> >> David T. Lewis wrote
>> >> > FFI based solutions work at a different level of abstraction than
>> >> > VM plugins, and there is a role for both.
>> >>
>> >> Thanks for the context, David. Now that we understand the different
>> >> niches,
>> >> the main problem is that they can not be loaded in the same image
>> without
>> >> breaking :/
>> >>
>> >
>> > The problem is to find a solution that works for both, Squeak and
>> Pharo
>> as
>> > well as for OSProcess and OSSubprocess.
>> >
>> > I guess one possibility is to modify both, OSProcess and OSSubprocess
>> > initialization of the child reaper so that they install the same
>> "generic"
>> > child reapear. Aside from initializating the child repear, they should
>> be
>> > added into an "observer list". When, when it comes the second project
>> to
>> get
>> > loaded it which check that a child reaper is already registered..in
>> which
>> > case he just register itself as "observer".
>> >
>> >  This child reaper should be generic enough (cannot be coupled to WHAT
>> to do
>> > when the semaphore is signaled). Using Announcements (or other
>> mechanisim
>> > that would work for Pharo and Squeak) we could simply "notify" the
>> > registered observers and each observer would do whatever is needed
>> (what
>> is
>> > actually now hardcoded in each child reaper)
>> >
>> > Maybe that works...just an idea.
>>
>> I think that looks like a nice design. Just one question: do we need
>> to track down whether the child reaper event should be directed to
>> OSProcess or to OSSubprocess? Wondering if there is an issue with one
>> of them trying to close the other one's resource (but I haven't
>> checked, so I may be wrong).
>>
>>
>>
>> Thierry
>>
>> >
>> >>
>> >>
>> >>
>> >> -
>> >> Cheers,
>> >> Sean
>> >> --
>> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> >>
>> >
>> >
>> > --
>> > Mariano
>> > http://marianopeck.wordpress.com
>>
>>
>

Re: [Pharo-users] Personal Programming onPharo

[David T. Lewis]

Trygve,

Thank you for pressing the SEND button with a shaking hand. I am inspired
by your words. But I am only 22 years younger than you, and I hope that
others are reading and appreciating what you have to say.

Dave


On Thu, May 10, 2018 at 12:02:44PM +0200, Trygve Reenskaug wrote:
> At 87, I'm an old man. I'm told that I don't understand modern software, 
> which is true. I use some programs daily: WIN7, Pharo, Thunderbird, ... 
> From time to time, I am told that a new version of the program that 
> fixes bugs and improves security is available. Press the button to 
> install it.?? So I wonder: Is modern software out of control? Does 
> /anybody /understand it, or is it so complicated that it is beyond human 
> comprehension? Why didn't they get it right the first time? Most of us 
> have the GOF book on Design Patterns on our bookshelf.?? In the 
> introduction, they write:
> 
>/An object-oriented program's runtime structure often bears little
>resemblance to its code structure. The code structure is frozen at
>compile-time; it consists of classes in fixed inheritance
>relationships. The runtime structure consists of rapidly changing
>networks of communicating objects.[GOF-95] p. 22./
> 
> ??and
> 
>/???, it's clear that code won't reveal everything about how a system
>will work. [ibid.p.23]/
> 
> Modern programmers are thus reduced to relying on testing the code. In 
> the words of Edsger Dijstra:
> 
>/"Program testing can be used to show the presence of bugs, but
>never to show their absence!"[REF] /
> 
> Modern programmers know all this but accept it as an unavoidable part of 
> progress. Some may have seen it as a challenge, but they are up against 
> the enormous inertia of a community who haven't changed their 
> fundamental model of programming since the advent of the von Neumann 
> stored program computer in 1948.
> 
> I can't resist another quote; this time from Tony Hoare's TuringAward 
> lecture:
> 
>/???There are two ways of constructing a software design: One way is
>to make it so simple that there are obviously no deficiencies and
>the other is to make it so complicated that there are no obvious
>deficiencies. The first method is far more difficult. ???[Hoare-81]/
> 
> In the lecture, Hoare was bemoaning his unsuccessful fight for 
> simplicity. Developers, particularly committees?? of developers, seem to 
> love complexity for its own sake. I have never accepted that bugs are an 
> unavoidable part of software.(See "2. ??Get it Right the First Time"?? 
> in the draft article). Bugs are parts of the facts of life but they are 
> not an acceptable part of it. Ideally, my software should be /so simple 
> that there are obviously no deficiencies. /One of my attempts at coming 
> to grips with the problem is the DCI programming paradigm. Here, /the 
> runtime structure of rapidly changing networks of communicating objects/ 
> is specified in explicit code that says (almost) everything about what 
> happens at runtime. Wouldn't it be wonderful if Pharo were to become 
> first to overcome the GOF limitation? I challenge you to play with 
> BabyIDE on Squeak?? and become convinced that it is a step in the right 
> direction.
> 
> I won't reread this message before I?? send it. I suppose it's 
> controversial and should probably delete some or all of it to avoid 
> angry answers. Another reason why I probably shouldn't send it is that I 
> do not have time to engage in a discussion. I /must /give priority to 
> finishing my article on DCI and PP. (A ~50 page draft is on my home 
> page; it will be updated from time to time)
> 
> I press the SEND button with a shaking hand
> --Trygve
> 
> 
> 
> On 09.05.2018 15:53, Richard O'Keefe wrote:
> >???I have a C++ program written in the late 80s by someone
> >else.?? It used to run fine under cfront 2.0 and early g++.
> >Ten years after it was written it was impossible to compile.
> >
> >*Since* that there have been changes to streams and strings,
> >amongst other things.
> >
> >The 1989 C standard changed the semantics of mixed signed/unsigned
> >integer arithmetic.?? It also inadvertently rendered illegal a
> >widely used technique.?? It is notoriously the case these days
> >that compilers taking the C standards literally have "broken"
> >quite a lot of code that worked with less ambitious compilers.
> >I have been watching this phenomenon with considerable
> >nervousness.?? See for example
> >http://www.eng.utah.edu/~cs5785/slides-f10/Dangerous+Optimizations.pdf 
> >
> >
> >I have certainly had previously acceptable C89 code be rejected
> >by compilers as not being legal C11.?? It is true that compilers
> >tend to have command line/IDE switches to ask that old code be
> >compiled under old rules, but you cannot say that *in* the program.
> >There is no way to mark the language version, no
> >?? #pragma stdc version 

Re: [Pharo-users] Where do we go now ?

[David T. Lewis]

On Fri, Apr 20, 2018 at 07:08:29AM -0700, Sean P. DeNigris wrote:
> Stephane Ducasse-3 wrote
> > I like when developers are talking about names:
> > They use a mac and not a computer, they were nike, lewis and not shoes
> > and pants
> > So guys can we focus our energy on positive things.
> 
> IHMO this is certainly a positive subject because it highlights the
> as-yet-to-be-resolved tension regarding understandability of the system
> between having a unique name (good for googling, distinguishing between
> versions) and a name that reveals what the project does/is for. What is the
> plan to resolve this because it is a real problem?
> 
> Nike and Levis are designed to stand on their own in front of the consumer
> market. Is this true of Nautilus, Calypso, or Epicea?

Sean,

Thank you for this clarification! I read Stef's message this morning
and I honestly thought that my name ("lewis") might have something to
do with pants. That probably would not be a good thing. But now I see
that we are talking about "levis" so I feel much better now :-)

Dave (Lewis, not Levis)

Re: [Pharo-users] Timespan translateToUTC problematic

[David T. Lewis]

Richard,

That is a very good explanation, and 100% correct.

Dave

On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote:
> I think the fundamental question is what a Date is supposed
> to represent.  I have spent a LOT of time thinking about date
> and time classes over the last 10 years, and have come to the
> conclusion that it makes no sense to view a Date as a Timespan.
> 
> Let's take an example.
> Christmas this year is going to be 2017-12-25 in every country
> that uses the Gregorian calendar and observes Christmas at all.
> If I ask the question
>"Is Christmas on the same date in Utah as it is in Otago?"
> I expect to get the answer YES.
> But if I ask the question
>"Is the span of time *called* Christmas day there same
> as the span of time *called* Christmas day here?"
> I expect to get the answer NO.
> 
> It's not entirely unlike the way that '95 Hanover Street'
> is the same street address in my city as '95 Hanover Street'
> in Edinburgh, but they correspond to quite different places.
> (Here: the Urgent Doctors; there: serviced apartments.)
> 
> Returning to Dates, I expect something like
>   aDate asTimespan: aTimeZone
> to return a timespan that might be 23, 24, or 25 hours
> (possibly plus an extra second), with *maybe*
>   aDate asTimespan
> meaning
>   aDate asTimespan: TimeZone here
> 
> Naturally the same goes for Weeks, Months, and Years, should
> they exist.
> 

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

[David T. Lewis]

On Sat, Oct 28, 2017 at 01:39:56PM +0200, Herby Vojk wrote:
> Hi,
> 
> I had to find out how to automatically deploy the backend written in 
> Pharo, and so far it uses docker-compose stop to stop the instance (and 
> later docker-compose up -d to get everything up again).
> 
> I noticed the stop phase takes a while and ends with status code 137. I 
> presume it ended forcefully and not gracefully.
> 
> What is the idiomatic way to wait on SIGTERM and close the process 
> gracefully?
> 
> Thanks, Herby

Try this:

  mySemaphore := OSProcess accessor forwardSigTerm.
  mySemaphore wait. "wait eg in a process until SIGTERM is detected"

Typically you would use #forwardSigTerm to set up the signal handler,
then start a Smalltalk process that waits on the semaphore and does
whatever you want to do when the Unix signal is detected.

You can do signal forwarding for any Unix signal, the #forwardSigTerm
is just a convenience method.

Dave

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[David T. Lewis]

I opened new issue 20167 for this.

Dave


On Mon, Jun 19, 2017 at 08:10:20AM +0200, Stephane Ducasse wrote:
> Thanks David.
> Once hilaire confirms it can you create a bug entry in pharo bug tracker?
> 
> S.
> 
> On Sun, Jun 18, 2017 at 9:37 PM, David T. Lewis <le...@mail.msen.com> wrote:
> > Hi Hilaire,
> >
> > I confirmed this on Squeak, and added a new test based on your example.
> >
> > The test is at
> >   
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194766.html,
> >
> > and the fix is
> >   
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194767.html
> >
> > I did not check a Pharo image, but I expect is the same issue for both Pharo
> > and Squeak. The problem is that PNGReadWriter is making 4 byte large 
> > integers,
> > then passing them as parameters to a primitive. On 64-bit Spur images, the
> > large integers need to be normalized to turn them into immediate short 
> > integers
> > prior to calling the primitive.
> >
> > This is a simple change to four methods so you can patch your image locally 
> > to
> > confirm the fix.
> >
> > HTH,
> > Dave
> >
> > On Sun, Jun 18, 2017 at 02:01:08PM +0200, Hilaire wrote:
> >> The code bellow decodes the PNG picture just fine in P3, in P6 it can't!
> >>
> >> I suspect changes in PNGReaderWriter>>nextImage
> >> However the version shows no history of edit :(
> >>
> >> One should add this code below in a test for PNG.
> >>
> >>
> >> PNGReadWriter createAFormFrom: #(137 80 78 71 13 10 26 10 0 0 0 13 73 72
> >> 68 82 0 0 0 48 0 0 0 48 16 6 0 0 0 7 146 37 196 0 0 0 6 98 75 71 68 255
> >> 255 255 255 255 255 9 88 247 220 0 0 0 9 112 72 89 115 0 0 0 72 0 0 0 72
> >> 0 70 201 107 62 0 0 1 153 73 68 65 84 120 218 237 155 73 110 195 48 12
> >> 69 227 162 183 211 9 180 11 130 220 77 39 208 249 210 77 181 8 81 69 19
> >> 39 169 255 109 12 35 137 197 255 105 81 244 144 219 13 0 0 0 0 0 116 16
> >> 66 8 33 188 94 214 113 120 99 214 151 111 238 1 115 206 57 231 235 178
> >> 54 68 10 238 19 112 58 1 189 1 238 158 16 233 25 255 37 117 224 221 141
> >> 215 210 193 158 128 83 140 215 210 181 156 0 26 216 169 139 180 155 210
> >> 218 50 184 124 126 74 34 122 245 204 234 101 207 224 41 221 145 150 14
> >> 49 67 118 77 132 118 220 98 93 208 168 64 107 172 226 18 63 19 91 194
> >> 172 103 132 117 124 106 194 117 132 210 227 215 143 103 109 124 65 173 4
> >> 181 4 173 149 128 254 223 121 49 190 160 190 6 212 4 126 22 94 12 163 91
> >> 173 241 229 112 219 141 188 51 106 184 223 46 139 162 62 3 164 137 49
> >> 198 24 253 117 89 219 241 183 145 181 82 180 94 154 192 47 212 248 247
> >> 253 209 45 152 102 205 120 36 130 137 182 193 159 19 5 22 233 53 158 126
> >> 31 48 209 54 190 181 15 8 189 247 215 71 141 174 25 127 218 243 137 105
> >> 168 17 53 99 164 140 247 154 8 183 119 67 139 177 41 165 148 210 117 209
> >> 125 233 241 181 16 187 18 158 21 254 124 62 30 247 251 186 241 173 113
> >> 122 227 148 70 237 145 100 175 33 210 120 139 207 205 237 232 255 22 71
> >> 129 45 16 60 3 158 163 123 6 140 214 74 239 198 207 198 201 189 102 12
> >> 151 32 26 128 155 23 150 22 105 189 96 38 181 88 31 211 206 113 163 165
> >> 151 109 17 182 110 231 118 213 193 222 5 237 154 8 171 184 217 254 31
> >> 176 123 9 114 255 146 177 187 128 224 3 0 0 0 0 192 198 252 0 102 116 72
> >> 96 211 171 62 8 0 0 0 0 73 69 78 68 174 66 96 130) asByteArray
> >>
> >>
> >>
> >> --
> >> Dr. Geo
> >> http://drgeo.eu
> >>
> >

Re: [Pharo-users] Regression with PNGReaderWriter in P6

[David T. Lewis]

Hi Hilaire,

I confirmed this on Squeak, and added a new test based on your example.

The test is at
  http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194766.html,

and the fix is
  http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-June/194767.html

I did not check a Pharo image, but I expect is the same issue for both Pharo
and Squeak. The problem is that PNGReadWriter is making 4 byte large integers,
then passing them as parameters to a primitive. On 64-bit Spur images, the
large integers need to be normalized to turn them into immediate short integers
prior to calling the primitive.

This is a simple change to four methods so you can patch your image locally to
confirm the fix.

HTH,
Dave

On Sun, Jun 18, 2017 at 02:01:08PM +0200, Hilaire wrote:
> The code bellow decodes the PNG picture just fine in P3, in P6 it can't!
> 
> I suspect changes in PNGReaderWriter>>nextImage
> However the version shows no history of edit :(
> 
> One should add this code below in a test for PNG.
> 
> 
> PNGReadWriter createAFormFrom: #(137 80 78 71 13 10 26 10 0 0 0 13 73 72
> 68 82 0 0 0 48 0 0 0 48 16 6 0 0 0 7 146 37 196 0 0 0 6 98 75 71 68 255
> 255 255 255 255 255 9 88 247 220 0 0 0 9 112 72 89 115 0 0 0 72 0 0 0 72
> 0 70 201 107 62 0 0 1 153 73 68 65 84 120 218 237 155 73 110 195 48 12
> 69 227 162 183 211 9 180 11 130 220 77 39 208 249 210 77 181 8 81 69 19
> 39 169 255 109 12 35 137 197 255 105 81 244 144 219 13 0 0 0 0 0 116 16
> 66 8 33 188 94 214 113 120 99 214 151 111 238 1 115 206 57 231 235 178
> 54 68 10 238 19 112 58 1 189 1 238 158 16 233 25 255 37 117 224 221 141
> 215 210 193 158 128 83 140 215 210 181 156 0 26 216 169 139 180 155 210
> 218 50 184 124 126 74 34 122 245 204 234 101 207 224 41 221 145 150 14
> 49 67 118 77 132 118 220 98 93 208 168 64 107 172 226 18 63 19 91 194
> 172 103 132 117 124 106 194 117 132 210 227 215 143 103 109 124 65 173 4
> 181 4 173 149 128 254 223 121 49 190 160 190 6 212 4 126 22 94 12 163 91
> 173 241 229 112 219 141 188 51 106 184 223 46 139 162 62 3 164 137 49
> 198 24 253 117 89 219 241 183 145 181 82 180 94 154 192 47 212 248 247
> 253 209 45 152 102 205 120 36 130 137 182 193 159 19 5 22 233 53 158 126
> 31 48 209 54 190 181 15 8 189 247 215 71 141 174 25 127 218 243 137 105
> 168 17 53 99 164 140 247 154 8 183 119 67 139 177 41 165 148 210 117 209
> 125 233 241 181 16 187 18 158 21 254 124 62 30 247 251 186 241 173 113
> 122 227 148 70 237 145 100 175 33 210 120 139 207 205 237 232 255 22 71
> 129 45 16 60 3 158 163 123 6 140 214 74 239 198 207 198 201 189 102 12
> 151 32 26 128 155 23 150 22 105 189 96 38 181 88 31 211 206 113 163 165
> 151 109 17 182 110 231 118 213 193 222 5 237 154 8 171 184 217 254 31
> 176 123 9 114 255 146 177 187 128 224 3 0 0 0 0 192 198 252 0 102 116 72
> 96 211 171 62 8 0 0 0 0 73 69 78 68 174 66 96 130) asByteArray
> 
> 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 

Re: [Pharo-users] Has anyone got some binary search code they like for the Collection class they want to share?

[David T. Lewis]

On Thu, May 18, 2017 at 10:18:34PM +0200, Sven Van Caekenberghe wrote:
> 
> > On 18 May 2017, at 21:08, Esteban A. Maringolo  wrote:
> > 
> > Great! How long has it been there? :)
> 
> Apparently since 2012 - can't really remember
> 

Looking at a Squeak 3.0 image I would say that they were introduced in 2000,
and the author was Andreas Raab.

Dave

Re: [Pharo-users] using UFFI in non-crashing way

[David T. Lewis]

On Sun, Mar 26, 2017 at 05:45:04PM +0200, Esteban Lorenzano wrote:
> 
> > On 26 Mar 2017, at 15:40, Peter Uhnak  wrote:
> > 
> > Hi,
> > 
> > is it possible to use UFFI and avoid crashing the image when the called 
> > code segfaults?
> > 
> > In other words, can I somehow wrap the call and throw in-image 
> > Exception/Error on failure instead of the whole thing crashing?
> 
> that???s not possible, once you segfault, you segfault.
> 
> > Or is the only way to do that have the called thing running as a separate 
> > app (e.g. via OSSubProcess) and communicate via pipes or sockets?
> 
> that???s not done. 
> no idea how much effort is required to implement, but I imagine is not 
> trivial. 
>

I have not tried it with FFI calls, but maybe this will do what you want:

  RemoteTask do: [ 2 + 2 ] ==> 4

Instead of [ 2 + 2 ] use some block containing your FFI calls.

It works in Pharo. To get RemoteTask, load OSProcess and CommandShell.
You also need Fuel, but I think that is in the image by default.

An explanation of RemoteTask is at http://wiki.squeak.org/squeak/6176.
You are right, it was not trivial to implement ;-)

HTH,
Dave
 

Re: [Pharo-users] [Pharo-dev] Mini Pharo -> JavaScript translator?

[David T. Lewis]

On Sat, Mar 11, 2017 at 06:16:26AM +0100, H. Hirzel wrote:
> On 3/10/17, Alexandre Bergel  wrote:
> > Hi!
> >
> > Is there a simple way to translate Pharo code into Javascript?
> > There is Pharo JS, but I cannot load it in Pharo 6. There is the amber
> > compiler, but I cannot find a version for Pharo.
> >
> > Amber takes the approach of translating everything into JavaScript,
> > including the Smalltalk object model. While this is great for fan of
> > bootstrapping images, it produces large javascript code.
> >
> > Is there a kind of Slang for JavaScript? I am looking for something
> > minimal.
> >
> > Cheers,
> > Alexandre
> 
> 
> Hello Alexandre
> 
> 
> Something like this
> https://github.com/ympbyc/LittleSmallscript
> 
> or
> 
> 
> http://wiki.squeak.org/squeak/5860 which refers to
> http://www.squeaksource.com/@xxu3r2Ma7SbqJi3E/1j-SgMCf (74000 downloads).
> 
> People have used it successfully.
> 
> There is probably a Pharo port.
> 

There is also an actual Slang code generator for Javascript, written
by Bert Freudenburg and used to generated the VM plugins for the
SqueakJS VM. You can find it in the VMMaker package (not VMMaker.oscog) 
at http://source.squeak.org/VMMaker, see class JSCodeGenerator.

Dave

Re: [Pharo-users] Problems with PipeableOSProcess

[David T. Lewis]

Hi Silas,

I am travelling and cannot help much right now, but to answer one of your
questions - yes, you can inspect errors in a PipeableOSProcess. It has an
"error pipeline stream" that will contain any output from the stderr
stream of the process.

It also has a process proxy for the actual external OS process, which will
show exit status for the process. In your case that probably will not help
much, because you will just see exit status for the /bin/shell that you
ran, not for the process that ran your perl script. Nevertheless it may be
interesting to check it.

One possible source of problems in a case like this is command line
parsing. The command line that you pass from Pharo may get parsed
differently than a normal bash terminal shell, especially with respect to
quoting strings. Also, you refer to an empty string, which certainly
sounds like it is related to the problem, although I cannot say why.

Dave


> Hi everyone,
>
>
>
> I'm currently experiencing problems with PipeableOSProcess. I'm using a
> command to run a third party tool, which reads a txt file and returns an
> XML
> string. In my collection, this works fine for about 75 out of 100 txt
> files,
> but fails on the remaining 25 ones. However, the tool itself doesn't fail.
> It works fine, if I issue the commands directly from a Terminal.
>
>
>
> Here's an example of a command string that works:
>
> /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/
> parsecit/bin/citeExtract.pl -m extract_all
> /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF
> sFromList/Ache00aScriptingCoordStyles.pdf.txt
>
>
>
> And here's an example of one that doesn't work.
>
> /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/tools/mac/
> parsecit/bin/citeExtract.pl -m extract_all
> /Users/silas/Documents/ExtendedEggShell/Moose6.0/ExtendedEggShell/examplePDF
> sFromList/Ardi97aSchemeTeaching.pdf.txt
>
>
>
> This is how I apply these commands through PipeableOSProcess:
>
>
>
> xml := (PipeableOSProcess command: cmdString) output.
>
>
>
> For the first command, xml is a large XML string, for the second command,
> it's just an empty string. As I've mentioned above, both commands work
> just
> fine in a Terminal. They both produce a correct XML string.
>
>
>
> Does anyone have an idea why this could be the case? Is there a way to
> access errors in the PipeableOSProcess, if there are any? Is there a
> better
> way to issue terminal commands from Pharo?
>
>
>
> Thanks for your help!
>
>
>
> Cheers,
>
> Silas
>
>

Re: [Pharo-users] Which is the best way of opening a PDF and HTML local files from Pharo

[David T. Lewis]

On Fri, Feb 24, 2017 at 01:07:18PM -0500, Offray Vladimir Luna C??rdenas wrote:
> Thanks Hilaire.
> 
> I was thinking in something that depend on OSProcess and invoke xdg-open 
> on Linux, for example, but is not working neither.
> 
> OSProcess command: 'xdg-open ', pdfPathString
> 
> doesn't open the PDF file :-/.
> 

Hi Offray,

I tried "OSProcess command: 'xdg-open ', pdfPathString" in Pharo, and it works
for me. Maybe check to be sure that pdfPathString is right?

Dave

Re: [Pharo-users] Use of -> in Pharo Code

[David T. Lewis]

On Tue, Nov 29, 2016 at 09:25:18PM -0800, Martin McClure wrote:
> On 11/29/2016 06:48 PM, Bruce Prior wrote:
> >I have been away from smalltalk coding for a while. On returning to 
> >the fold, I often see the use of a right arrow in code. Is this 
> >something new?
> >
> >Today in a Teapot app example, I saw,
> >
> >Teapot on GET: '/welcome' -> 'Hello World!'; start.
> >
> >What is the arrow for?
> 
> As Sebastian said, #-> is a message that creates an Association, with 
> the receiver as the key and the argument as the value of the 
> Association. This has actually been around a very long time, though 
> perhaps it's getting more widely used these days. It doesn't appear to 
> be in the Blue Book, but I think it was probably actually in the 
> Smalltalk-80 image 1 release.
> 
> I'm not *quite* curious enough to verify that by rooting around in my 
> basement for the machine that actually runs that version and seeing if 
> it will still power up after all these years. :-)
> 
> Regards,
> 
> -Martin
>

It is present in the Squeak 1.13 image of 1996, which I think is fairly
close to Blue Book.

You can run that original image from this web page:

 http://try.squeak.org

Dave
 

Re: [Pharo-users] OSProcess lock image

[David T. Lewis]

On Wed, Oct 19, 2016 at 10:03:15PM +0200, Hilaire wrote:
> Hi Paul,
> 
> Thanks for the tips.
> My image was running for days with the computer going to sleep
> regularly. Restarting the image solved the problem.

That is interesting and helpful, thanks. The process that receives notification
of child process exit (unix SIGCHLD signal) spends most of its time waiting
on a semaphore with timeout, see UnixOSProcessAccessor>>grimReaperProcess.
Maybe there is some kind of issue with the timeout if the image is paused
while the computer is put to sleep.

Dave

> 
> Hilaire
> 
> Le 15/10/2016 ? 20:00, Paul DeBruicker a ?crit :
> > I have no idea why it happens but sometimes OSProcess resumes working after
> > doing a 
> > 
> > OSProcessAccessor initialize.
> > 
> > in a workspace.
> > 
> > 
> > Hope this helps
> > 
> > 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 

Re: [Pharo-users] OSProcess command with german umlaut does not work

[David T. Lewis]

On Mon, Jun 06, 2016 at 08:34:40PM +0200, Sven Van Caekenberghe wrote:
> 
> > On 06 Jun 2016, at 17:22, Sabine Manaa  wrote:
> > 
> > why ByteArray?
> 
> http://www.unicode.org/faq/utf_bom.html
> 
> A Unicode transformation format (UTF) is an algorithmic mapping from every 
> Unicode code point (except surrogate code points) to a unique byte sequence.
> 
> https://en.wikipedia.org/wiki/UTF-8
> 
> UTF-8 encodes each of the 1,112,064 valid code points in the Unicode code 
> space (1,114,112 code points minus 2,048 surrogate code points) using one to 
> four 8-bit bytes (a group of 8 bits is known as an octet in the Unicode 
> Standard).
> 
> In Pharo
> 
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Zinc-Encoding-Meta/Zinc-Encoding-Meta.html
> 
> Of course, given a ByteArray, whose values are all between 0 and 255 by 
> definition, you can convert it to a ByteString. That String is not a correct 
> (Pharo) String anymore, it is like converting a PNG or JPEG to String, you 
> can do it, it is just wrong.
> 
> When talking to the outside world, be it over a network connection, or via 
> primitive calls, anything but pure ASCII strings need an encoding. This has 
> to be agreed upon by both parties. If the receiving party wants UTF-8 forced 
> into a (kind of) String, that is (still) possible.
> 
> Your initial solution seems to indicate that this is expected. This (ugly) 
> conversion should be done at an as low level as possible, IMHO.
> 

Hi Sven,

Thanks for this concise summary. I think perhaps what is conceptually
a problem in my OSProcess implementation is that I allow command arguments
to be given in the form of Strings, then pass the byte array contents of
those Squeak/Pharo Strings to a Unix shell or to an exec() system call.
This is convenient from my point of view, because strings are very easy
to use, but it does not account for the differences in mapping from a
String to a byte array. It is the byte array that is actually used in
the calls to the operating system such as:

  UnixOSProcessAccessor>>primForkExec: executableFile
stdIn: inputFileHandle
stdOut: outputFileHandle
stdErr: errorFileHandle
argBuf: argVec
argOffsets: argOffsets
envBuf: envVec
envOffsets: envOffsets
workingDir: pathString

At this point, the argVec is composed of "strings" in the C sense of the
word, which really means that it contains byte array data from the Strings.
And of course, if the string encodings in the Squeak/Pharo strings do not
happen to match the string encodings of the operating system, then indeed
the byte arrays do not match and we get a "file not found" kind of problem.

My hope is that Mariano's assessment is correct, and that we can treat
this as the right way to handle the encoding match issues: 

On Mon, Jun 06, 2016 at 01:59:21PM -0300, Mariano Martinez Peck wrote:
> Hi Dave, Sabine, Norbert et all,
>
> Few weeks (months?) ago I was also reviewing this topic of encoding a
> OS(Sub)Process. After surfing a bit the web, I found out the most simple
> and accurate answer/solution was indeed to set the correct locale and/or
> text encoding in the computer in question. Anyway...more answers below.

This certainly sounds like the Right Thing To Do if only it works :-)

Dave

Re: [Pharo-users] OSProcess command with german umlaut does not work

[David T. Lewis]

Norbert,

You are probably right. I'm not sure the best way to handle it.

Dave

> Dave,
>
>> Am 06.06.2016 um 18:13 schrieb David T. Lewis <le...@mail.msen.com>:
>>
>> Hi Sabine,
>>
>> That's great that #utf8Encoded is working, thanks for confirming.
>>
>> I'll look and see if I can add that to OSProcess (I'm traveling and
>> cannot
>> look at it right now).
>>
>> Mariano - this thread probably applies to OSSubProcess also.
>>
> that would just work if the system locale is utf8, right? Wouldn't it be
> better to making that a setting?
>
> Norbert
>
>> Dave
>>
>>> Hi Sven,
>>>
>>> why ByteArray?
>>>
>>> does not work (Improper store into indexable object):
>>> OSProcess   command: ('cp
>>> /Library/WebServer/Documents/reports/bär.pdf
>>> /Library/WebServer/Documents/reports/test-a.pdf' utf8Encoded asString).
>>>
>>> works:
>>> OSProcess   command: ('cp
>>> /Library/WebServer/Documents/reports/bär.pdf
>>> /Library/WebServer/Documents/reports/test-a.pdf' utf8Encoded)
>>>
>>> Perhaps David can add this here:
>>>
>>> command: aCommandString
>>> "Run a command in a shell process. Similar to the system(3) call in the
>>> standard C library,
>>> except that aCommandString runs asynchronously in a child process. The
>>> command is
>>> run by a ConnectedUnixProcess in order to facilitate command pipelines
>>> within Squeak."
>>>
>>> "UnixProcess thisOSProcess command: 'ls -l /etc'"
>>>
>>> | proc |
>>> pid isNil
>>> ifTrue:
>>> [self class noAccessorAvailable. ^nil]
>>> ifFalse:
>>> [proc := self
>>> forkJob: ExternalUnixOSProcess defaultShellPath
>>> arguments: (Array with: '-c' with: aCommandString utf8Encoded asString)
>>> <<<===
>>> environment: nil
>>> descriptors: nil.
>>> proc ifNil: [self class noAccessorAvailable].
>>> ^ proc]
>>>
>>>
>>> regards
>>> Sabine
>>>
>>>
>>>>
>>>>
>>>
>>> 2016-06-06 8:41 GMT+02:00 Sabine Manaa <manaa.sab...@gmail.com>:
>>>
>>>> Hi Dave,
>>>>
>>>> I get the german ä with:
>>>>
>>>> (Character value: 228) asString
>>>>
>>>> Do you want me to go in it and suggest a solution or do you want to
>>>> try
>>>> to
>>>> fix it and I test it?
>>>>
>>>> Thanks for helping!
>>>>
>>>> Regards Sabine
>>>>
>>>> 2016-06-05 23:08 GMT+02:00 David T. Lewis [via Smalltalk] <[hidden
>>>> email]
>>>> <http:///user/SendEmail.jtp?type=node=4899318=0>>:
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> If you reply to this email, your message will be added to the
>>>>> discussion
>>>>> below:
>>>>>
>>>>> http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp4899285p4899301.html
>>>>> To start a new topic under Pharo Smalltalk Users, email [hidden
>>>>> email]
>>>>> <http:///user/SendEmail.jtp?type=node=4899318=1>
>>>>> To unsubscribe from Pharo Smalltalk Users, click here.
>>>>> NAML
>>>>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: Re: OSProcess command with german umlaut
>>>> does not work
>>>> <http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp4899285p4899318.html>
>>>> Sent from the Pharo Smalltalk Users mailing list archive
>>>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at
>>>> Nabble.com.
>>>>
>>>
>>
>>
>>
>
>

Re: [Pharo-users] OSProcess command with german umlaut does not work

[David T. Lewis]

Hi Sabine,

That's great that #utf8Encoded is working, thanks for confirming.

I'll look and see if I can add that to OSProcess (I'm traveling and cannot
look at it right now).

Mariano - this thread probably applies to OSSubProcess also.

Dave

> Hi Sven,
>
> why ByteArray?
>
> does not work (Improper store into indexable object):
> OSProcess   command: ('cp  /Library/WebServer/Documents/reports/bär.pdf
> /Library/WebServer/Documents/reports/test-a.pdf' utf8Encoded asString).
>
> works:
> OSProcess   command: ('cp  /Library/WebServer/Documents/reports/bär.pdf
> /Library/WebServer/Documents/reports/test-a.pdf' utf8Encoded)
>
> Perhaps David can add this here:
>
> command: aCommandString
> "Run a command in a shell process. Similar to the system(3) call in the
> standard C library,
> except that aCommandString runs asynchronously in a child process. The
> command is
> run by a ConnectedUnixProcess in order to facilitate command pipelines
> within Squeak."
>
> "UnixProcess thisOSProcess command: 'ls -l /etc'"
>
> | proc |
> pid isNil
> ifTrue:
> [self class noAccessorAvailable. ^nil]
> ifFalse:
> [proc := self
> forkJob: ExternalUnixOSProcess defaultShellPath
> arguments: (Array with: '-c' with: aCommandString utf8Encoded asString)
> <<<===
> environment: nil
> descriptors: nil.
> proc ifNil: [self class noAccessorAvailable].
> ^ proc]
>
>
> regards
> Sabine
>
>
>>
>>
>
> 2016-06-06 8:41 GMT+02:00 Sabine Manaa <manaa.sab...@gmail.com>:
>
>> Hi Dave,
>>
>> I get the german ä with:
>>
>> (Character value: 228) asString
>>
>> Do you want me to go in it and suggest a solution or do you want to try
>> to
>> fix it and I test it?
>>
>> Thanks for helping!
>>
>> Regards Sabine
>>
>> 2016-06-05 23:08 GMT+02:00 David T. Lewis [via Smalltalk] <[hidden
>> email]
>> <http:///user/SendEmail.jtp?type=node=4899318=0>>:
>>
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the
>>> discussion
>>> below:
>>>
>>> http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp4899285p4899301.html
>>> To start a new topic under Pharo Smalltalk Users, email [hidden email]
>>> <http:///user/SendEmail.jtp?type=node=4899318=1>
>>> To unsubscribe from Pharo Smalltalk Users, click here.
>>> NAML
>>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>> --
>> View this message in context: Re: OSProcess command with german umlaut
>> does not work
>> <http://forum.world.st/OSProcess-command-with-german-umlaut-does-not-work-tp4899285p4899318.html>
>> Sent from the Pharo Smalltalk Users mailing list archive
>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at
>> Nabble.com.
>>
>

Re: [Pharo-users] OSProcess command with german umlaut does not work

[David T. Lewis]

I think that Hilaire is right, although I don't know enough to say
how to handle the issue properly.

I tried making a unix file called b??r.pdf. I did this by
pasting the name with umlout from Sabine's email. I don't understand
the encodings (and my system is set up as US English), but I can say
that this created a file in my Linux file system with a name that appears
as expected, and includes the $a with umlout.

If I paste the same string into my image (Squeak in my case, but I expect
it should be similar in Pharo), then I find that I am working with a string
in which the $a with umlaut is a single character with value 220.

The OSProcess error that Sabine reports is apparently a result of this
mismatch in encodings. I see an error message on my console window that
also displays the file name differently (this is the stderr output from
the OSProcess command, showing a file not found condition).

I don't know if ZnCharacterEncoder handles the issue properly, but I
would be happy to hear if it does :-)

Apologies in advance if I am confused on character encoding, but I am
trying to understand the issue that Sabine reported.

Thanks,
Dave


On Sun, Jun 05, 2016 at 09:40:31PM +0200, Sven Van Caekenberghe wrote:
> 
> > On 05 Jun 2016, at 21:07, Hilaire  wrote:
> > 
> > Hello Sabine,
> > 
> > Just a suggestion.
> > If your string is not pure ascii you may need to convert it to UTF8
> > first as this is what likely expect your OS host.
> > 
> > Indeed Pharo string are not internally encoded as utf8
> 
> If that is the case, that the OS expects a different encoding, then the 
> OS(Sub)Process implementation should deal with it, not the user of the API.
> 
> > Check the UTF8TextConverter class to do so.
> 
> No, these converters are conceptually wrong, since they encode String to 
> String, while it should be String to ByteArray.
> 
> The ZnCharacterEncoder hierarchy should be used instead.
> 
> String>>#utf8Encoded is a convenience method that can be used to do a quick 
> conversion.
> 
> > Hilaire
> > 
> > Le 05/06/2016 18:39, Sabine Manaa a ??crit :
> >> on command line, this works, my file is copied:
> >> cp  /Library/WebServer/Documents/reports/b??r.pdf
> >> /Library/WebServer/Documents/reports/test.pdf
> >> 
> >> In Pharo (4+5) this does not work (file not copied, no error message)
> >> OSProcess command: 'cp  /Library/WebServer/Documents/reports/b??r.pdf
> >> /Library/WebServer/Documents/reports/test-a.pdf'.  
> >>
> >> This works (file is copied):
> >> OSProcess  command: 'cp  /Library/WebServer/Documents/reports/bar.pdf
> >> /Library/WebServer/Documents/reports/test-b.pdf'. 
> >> 
> >> Seems that german umlauts don't work.
> >> 
> >> Is there something, I can I do, I don't want to replace the umlauts in
> >> filenames...
> >> 
> >> Regards
> >> Sabine
> >> 
> >> 
> > 
> > -- 
> > Dr. Geo
> > http://drgeo.eu
> > 
> > 
> 

Re: [Pharo-users] OT - an opinion on node.js

[David T. Lewis]

On Mon, May 23, 2016 at 09:50:32PM +0800, Ben Coman wrote:
> On Mon, May 23, 2016 at 4:44 PM, Peter Uhn??k  wrote:
> > The video is intentionally inflammatory and I don't really see a reason why
> > we would need to either start a flame war (if there are node.js devs reading
> > it), or an echo chamber (so we all just put ourselves on the back hour great
> > our Pharo is).
> >
> >> Never used it.
> >> I'd be interested to hear any counter opinons.
> >
> > wtf?
> 
> you a right. I'm embarrassed I didn't think it through.
> I apologise, it was out of line.
> -ben

Don't feel too badly, I for one got a good laugh out of it :-)

Dave

Re: [Pharo-users] [Pharo-dev] [ANN] OSSubprocess first milestone

[David T. Lewis]

On Thu, Jan 14, 2016 at 03:33:56PM -0300, Mariano Martinez Peck wrote:
> Dear all,
> 
> I am happy to tell you I have a first prototype of the tool for executing
> OS processes:
> 
> https://github.com/marianopeck/OSSubprocess
> 
>  As I said many times, the main idea was to be as much as possible
> FFI-based, only for executing OS commands and, from my point of view, a
> better end-user API. Also, as for the first step, I had to focus on
> Linux/OSX.
> 
> I would like to thank Pharo Consortium for the sponsor of this development
> effort. Here is the first milestone!

Bravo Mariano!

Dave

Re: [Pharo-users] RemoteTask does not work on Macos

[David T. Lewis]

On Mon, Dec 21, 2015 at 01:23:35PM +, Dimitris Chloupis wrote:
> I tried to run the parrarelExample method of RemoteTask class which is
> loadable from CommandShell project and it seems it looks for a plugin that
> cant find.
> 
> It gives me a warning
> 
> forkSqueak requires XDispalyControlPlugin
> 
> if I proceed I get another warning
> 
> process accessor module not available
> 
> if i proceed I get MNU: receiver of "pid" is nil

I think that your VM is missing a couple of necessary plugins. The
XDisplayControlPlugin is used to close the socket connection to the
X display in the new child VM/image. You may also be missing the
OSProcessPlugin.

Note, I developed this in Squeak on Linux, so it may be that some work
would be needed for Pharo. If you have a Squeak image handy, you might
want to look at it there.

Dave

Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

[David T. Lewis]

Mariano,

I am really happy to see this and I look forword to helping you in
any way I can.

Dimitris,

It is really interesting that you should suggest this. I think it may
be a bit off topic for Mariano's initial goals, but Mariano is the
driving force behind Fuel, which is the serializer that I use for
RemoteTask in OSProcess/CommandShell. This attempts to do much of
what you suggest, using Fuel to return the results of processing
executed in a forked image (in the unix sense of "forked", i.e.
extremely memory efficient).

So maybe if I can help Mariano with his project (which of course I
plan to do anyway), then he might be able to help me turn RemoteTask
into something reliable enough for general purpose use.

Another nice connection here is that Eliot's Spur image model will
make #forkSqueak (the primitive behind RemoteTask) more efficient
in cases where the cooperating images do a lot of processing, because
memory changes are more localized in the Spur memory model. In principle
it should be possible to run very large object memories in 64-bit Spur,
while forking cooperating images that consume very little additional
real memory.

Dave


On Sat, Dec 19, 2015 at 01:33:07PM +, Dimitris Chloupis wrote:
> I am very excited for such a project.
> 
> I hope you manage to fix the stdout problem on macos.
> 
> One thing I would like to see is an expansion of the ability of OSProcess
> to launch multiple instances of pharo and make them communicate with each
> other. Thats a way to have pharo running on multiple cores. Maybe establish
> a framework of communication of images that will be based on the existing
> design of the fork mechanism in Pharo.
> 
> Python is doing something similar with multiprocessing module  which
> launches multiple processes of cpython executable and makes them
> communication with each other through a similar api to its threading
> module. This way python takes advantage of multiple cores. Python threads
> like pharo are green threads and pharo like python has a GIL like
> mechanism.
> 
> Taking into account that current computers have at least 4 cores, its not a
> bad idea to speed up pharo like this at least  400% ;)
> 
> On Sat, Dec 19, 2015 at 3:24 PM Mariano Martinez Peck 
> wrote:
> 
> > Dear all,
> >
> > I am tremendously happy to announce you that Pharo Consortium will sponsor
> > yet another development effort. In this particular case, it's my honor to
> > carry on such an effort and I will be developing and improving a few things
> > and ideas. All the contract and paperwork has already been done so it's
> > time to start working.
> >
> > Regarding the developments itself, we discussed about these topics:
> >
> > 1) Experiment with a simpler yet more limited OSProcess alternative to
> > execute OS commands.
> > 2) Improving FileSystem in order to better deal with some POSIX stuff like
> > symbolic links, unix file permissions, etc etc.
> >
> > I have already started with 1). OSProcess is super complete and it
> > involves some packages (OSProcess / CommandShell) as well as some VM
> > plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features
> > (like forking the running image) but we would like to focus only in
> > executing OS commands. In addition, OSProcess dates from quite some years
> > ago when many of the current infrastructure features did not exist yet.
> >
> > So the idea is to think a simpler alternative to execute OS commands,
> > using new features such as threaded FFI (for example, for reading async
> > from pipes), pinned objects, etc. We want to use FFI as much as possible
> > rather than VM plugins.
> >
> > From the image side, we are thinking about an API which would look like a
> > builder-like API (FileSystem, XStream, etc).
> >
> > We have been discussing with David Lewis (OSProcess author) as well as
> > with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc
> > in order to agree in a project that would be worth doing (otherwise we
> > would continue using existing tools). And they have all been very kind with
> > me providing positive discussions.
> >
> > I will soon do a survey to measure the most common use cases of OSProcess
> > and related tools.
> >
> > If you have any thought, question, feedback, or whatever, please let us
> > know.
> >
> > Finally, note that I will be doing this project together with another
> > client's project (Quuve) and my life does not have much free time these
> > days...so please be patient!!!
> >
> > Best,
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >

Re: [Pharo-users] Trying to understand OSProcess on MacOS Yosemite

[David T. Lewis]

Yes, that is normal. You are reading the output stream, and after it has
been read (up to EOF) it will be empty.

Glad it is working for you now :-)

Dave

> additionally if inspect output a second time , the stdout string is gone,
> so maybe it flushes / deletes it ? is this normal ?
>
> On Fri, Nov 6, 2015 at 11:30 AM Dimitris Chloupis <kilon.al...@gmail.com>
> wrote:
>
>> looks like a vm problem after instruction of Thierry instead of
>>
>> wget -O- get.pharo.org/50+vmLatest | bash
>>
>> I did
>>
>> wget -O- get.pharo.org/50+vm | bash
>>
>> and now it works fine I can see the output with an inspection.
>>
>> Looks like something changed in the vm that broke this.
>>
>> On Fri, Nov 6, 2015 at 10:23 AM Dimitris Chloupis
>> <kilon.al...@gmail.com>
>> wrote:
>>
>>> good to know I am not the only one with this problem :) so how may I
>>> help
>>> solving this problem ?
>>>
>>> On Fri, Nov 6, 2015 at 10:11 AM john pfersich <jpfers...@gmail.com>
>>> wrote:
>>>
>>>> I tested what I posted on a fresh Pharo 4.0 image on OSX 10.10
>>>> (Yosemite) so it sounds like something's wrong in the trunk.
>>>>
>>>> On Thu, Nov 5, 2015 at 10:38 PM, Dimitris Chloupis <
>>>> kilon.al...@gmail.com> wrote:
>>>>
>>>>> It says I am using Cog 4.3.3
>>>>>
>>>>> I also used the code of John pfersich
>>>>>
>>>>> p :=(PipeableOSProcess waitForCommand: 'ls') .
>>>>> p output.
>>>>>
>>>>> and it still returns an empty string while the process is
>>>>>
>>>>> "a PipeableOSProcess on an ExternalUnixOSProcess with pid 769 on
>>>>> /bin/sh (complete, normal termination with status 0)"
>>>>>
>>>>> I tried debugging but it froze the image with a
>>>>>
>>>>> UndefinedObject(Object)>>doesNotUnderstand: #stepToCallee
>>>>>
>>>>> this happened inside BlockClosure >> newProcess at Processor
>>>>> terminateActive
>>>>>
>>>>> When I execute the command it works fine because I can see the output
>>>>> in the terminal.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 6, 2015 at 5:23 AM David T. Lewis <le...@mail.msen.com>
>>>>> wrote:
>>>>>
>>>>>> On Fri, Nov 06, 2015 at 12:41:58AM +, Dimitris Chloupis wrote:
>>>>>> > hello David and thank you for your help and your detailed
>>>>>> explanation.
>>>>>> >
>>>>>> > as I said I used
>>>>>> >
>>>>>> > p :=(PipeableOSProcess command: 'ls') . p output.
>>>>>> >
>>>>>> > and it just returns an empty string.
>>>>>>
>>>>>> The way this should work is that p (an instance of
>>>>>> PipeableOSProcess)
>>>>>> should
>>>>>> answer its output up to EOF (end of file) on the stdout from the
>>>>>> process.
>>>>>>
>>>>>> Can you please try stepping through this slowly in a debugger, and
>>>>>> see
>>>>>> if
>>>>>> it works? Or put "(Delay forSeconds: 1)" right before you do "p
>>>>>> output"?
>>>>>> I am guessing that there may be something about the OSProcessPlugin
>>>>>> in
>>>>>> your
>>>>>> VM that is causing EOF detection to fail, such that you just get an
>>>>>> empty
>>>>>> string as output.
>>>>>>
>>>>>> I do not have a Mac to test, so I am only guessing. It might also be
>>>>>> a
>>>>>> bug in the OSProcess plugin, I'm not sure.
>>>>>>
>>>>>> Just to help me identify what your are running, could you please
>>>>>> evaluate
>>>>>> "OSProcess accessor osppModuleVersionString" and let me know what it
>>>>>> says?
>>>>>> The current version would be '4.6.1' but other versions may be in
>>>>>> circulation,
>>>>>> and that could affect EOF detection.
>>>>>>
>>>>>> Thanks,
>>>>>> Dave
>>>>>>
>>>>>>
>>

Re: [Pharo-users] Trying to understand OSProcess on MacOS Yosemite

[David T. Lewis]

On Thu, Nov 05, 2015 at 09:50:29PM +, Dimitris Chloupis wrote:
> So I try to understand how OSProcess work exactly to find why filetree
> seems not able to use it and generating the error I already reported
> earlier.
> 
> Using something simple like
> 
> OSProcess command:'pwd'
> 
> works great , I have the terminal open and I can see the correct return
> value of the command in my terminal but for some reason I can find no such
> info when I inspect the above example. So how exactly OSProcess returns the
> output of the terminal ? Is there an instance variable of some sort ?
> Because I tried to inspect it deeply and I found nothing . Can you help me
> understand how OSProcess work ? Because If I do understand it then I can
> find what the problem is .

Hi Dimitris,

The OSProcess and CommandShell packages provide a variety of ways to
create and interact with operating system processes. In the case of
"OSProcess command: 'pwd'" it is starting a new unix shell (/bin/sh, which
on most systems is the Bash shell). Once it starts the shell, it asks
the shell to evaluate the 'pwd' command. In this case, you would see the
output of that 'pwd' command appearing in the terminal window for your
Pharo VM process.

If you inspect the result of this, you should see an instance of
ExternalUnixOSProcess. This is a proxy that represents the operating
system process that was used to run /bin/sh. It should look something like
this:

an ExternalUnixOSProcess with pid 10703 on /bin/sh (complete, normal 
termination with status 0)

The exitStatus instance variable of the ExternaUnixProcess should be 0 in
this example, which means only that the shell ran successfully (It does not
tell you exit status of the 'pwd' command in this case, although there are
other ways to do that).

There are other classes, especially PipeableOSProcess and CommandShell,
that support higher level control of OS processes, with direct connection
of the stdin/stdout/stderr streams to your Smalltalk image. I expect that
filetree would be using these higher level abstractions.

I don't know if this helps with your problem but maybe it gives you some
ideas.

Dave

Re: [Pharo-users] Trying to understand OSProcess on MacOS Yosemite

[David T. Lewis]

On Thu, Nov 05, 2015 at 10:22:31PM -0500, David T. Lewis wrote:
>
> Or put "(Delay forSeconds: 1)" right before you do "p output"?

Sorry, I meant to say:

   "(Delay forSeconds: 1) wait" right before you do "p output"?

Dave

Re: [Pharo-users] Slow compilation on one of my Windows PCs

[David T. Lewis]

On Wed, Jul 01, 2015 at 01:39:25AM +0200, Nicolai Hess wrote:
 2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck marianop...@gmail.com:
 
  Then the only thing I can think of is a vm primitive that is implemented
  differently in linux/mac than windows vm...
 
 
 Yes, the vm primitives, like I already told some messages above.
 FilePrimitives ARE slow on windows.

Is that actually true? I have not done any work on Windows in a while, but
I recall that file primitives on Windows were quite efficient. They work
differently because they operate at the level of direct file handles rather
than stdio streams, but this may be faster in many cases. So unless you
have measurable evidence that the Windows IO is slower, don't assume it
to be true.

Dave

Re: [Pharo-users] Monticello / OS deadlock ?

[David T. Lewis]

 basicNew:
 primSQFileSetBlocking:
 basicNew:
 basicAt:put:
 basicNew:
 basicAt:put:
 at:put:
 basicNew
 primSigPipeNumber
 basicNew
 wait
 at:put:
 signal
 primForwardSignal:toSemaphore:
 wait
 at:put:
 signal
 primCreatePipe
 new:
 at:put:
 at:put:
 basicNew
 basicNew:
 basicNew
 basicNew:
 primSQFileSetNonBlocking:
 basicNew:
 basicAt:put:
 basicNew:
 basicAt:put:
 at:put:
 basicNew
 signal
 basicNew:
 basicAt:put:
 basicNew:
 basicAt:put:
 at:put:
 new:
 basicNew
 new:
 replaceFrom:to:with:startingAt:
 basicNew
 basicNew:
 primSQFileSetNonBlocking:
 basicNew
 stringHash:initialHash:
 primOSFileHandle:
 basicNew
 wait
 at:put:
 signal
 primAioEnable:forSemaphore:externalObject:
 basicNew
 objectAt:
 basicNew:
 stackp:
 basicNew
 primitiveResume
 wait
 wait
 signal
 wait
 signal
 primAioHandle:exceptionEvents:readEvents:writeEvents:
 signal
 basicNew:
 basicAt:put:
 primSQFileSetNonBlocking:
 basicNew:
 basicAt:put:
 basicNew:
 basicAt:put:
 at:put:
 basicNew
 basicNew
 wait
 signal
 primUTCMicrosecondsClock
 +
 =
 +
 
 primSignal:atUTCMicroseconds:
 wait
 signal
 wait
 wait
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 primUTCMicrosecondsClock
 =
 signal
 +
 primSignal:atUTCMicroseconds:
 wait
 basicNew
 basicNew
 basicNew
 basicNew
 signal
 basicNew
 signal
 basicNew
 new:
 wait
 new:
 at:put:
 at:put:
 at:put:
 basicNew:
 at:put:
 basicNew:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 basicNew
 new:
 at:put:
 new:
 basicNew:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 at:put:
 basicNew:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 at:put:
 at:put:
 at:put:
 new:
 replaceFrom:to:with:startingAt:
 primSizeOfPointer
 new:
 at:put:
 at:put:
 at:put:
 primSizeOfPointer
 basicNew:
 basicNew
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 new:
 basicNew
 new:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 at:put:
 new:
 replaceFrom:to:with:startingAt:
 new:
 at:put:
 at:put:
 primGetCurrentWorkingDirectory
 basicNew:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 primForkExec:stdIn:stdOut:stdErr:argBuf:argOffsets:envBuf:envOffsets:workingDir:
 primGetPid
 primGetPid
 primGetPid
 basicNew
 basicNew
 wait
 at:put:
 signal
 wait
 shallowCopy
 new:
 replaceFrom:to:with:startingAt:
 signal
 wait
 replaceFrom:to:with:startingAt:
 at:put:
 signal
 primCloseNoError:
 primCloseNoError:
 primCloseNoError:
 signal
 basicNew:
 basicNew
 basicNew
 basicNew
 wait
 signal
 primUTCMicrosecondsClock
 +
 =
 +
 
 primSignal:atUTCMicroseconds:
 wait
 signal
 wait
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 basicNew:
 primRead:into:startingAt:count:
 basicNew
 signal
 wait
 basicNew:
 basicNew
 basicNew:
 replaceFrom:to:with:startingAt:
 replaceFrom:to:with:startingAt:
 signal
 basicNew
 signal
 basicNew
 new:
 wait
 signal
 wait
 signal
 primAioHandle:exceptionEvents:readEvents:writeEvents:
 signal
 wait
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 relinquishProcessorForMicroseconds:
 
 stack page bytes 4096 available headroom 3300 minimum unused headroom 2152
 
 (SIGUSR1)
 
 
 2015-06-03 14:15 GMT+02:00 David T. Lewis le...@mail.msen.com:
 
  On Wed, Jun 03, 2015 at 07:05:15AM +0200, Thierry Goubier wrote:
   Hi Dave,
  
   Le 03/06/2015 03:15, David T. Lewis a ?crit :
   Hi Thierry and Jose,
   
   I am reading this thread with interest and will help if I can.
   
   I do have one idea that we have not tried before. I have a theory that
   this may
   be an intermittent problem caused by SIGCHLD signals (from the external
  OS
   process
   when it exits) being missed by the
  UnixOSProcessAccessorgrimReaperProcess
   that handles them.
   
   If this is happening, then I may be able to change grimReaperProcess to
   work around the problem.
   
   When you see the OS deadlock condition, are you able tell if your Pharo
  VM
   process has subprocesses in the zombie state (indicating that
   grimReaperProcess
   did not clean them up)? The unix command ps -axf | less will let you
  look
   at the process tree and that may give us a clue if this is happening.
  
   I found it very easy to reproduce and I do have a zombie children
   process to the pharo process.
 
  Jose confirms this also (thanks).
 
  Can you try filing in the attached UnixOSProcessAccessorgrimReaperProcess
  and see if it helps? I do not know if it will make

Re: [Pharo-users] Monticello / OS deadlock ?

[David T. Lewis]

On Wed, Jun 03, 2015 at 07:05:15AM +0200, Thierry Goubier wrote:
 Hi Dave,
 
 Le 03/06/2015 03:15, David T. Lewis a ?crit :
 Hi Thierry and Jose,
 
 I am reading this thread with interest and will help if I can.
 
 I do have one idea that we have not tried before. I have a theory that 
 this may
 be an intermittent problem caused by SIGCHLD signals (from the external OS 
 process
 when it exits) being missed by the UnixOSProcessAccessorgrimReaperProcess
 that handles them.
 
 If this is happening, then I may be able to change grimReaperProcess to
 work around the problem.
 
 When you see the OS deadlock condition, are you able tell if your Pharo VM
 process has subprocesses in the zombie state (indicating that 
 grimReaperProcess
 did not clean them up)? The unix command ps -axf | less will let you look
 at the process tree and that may give us a clue if this is happening.
 
 I found it very easy to reproduce and I do have a zombie children 
 process to the pharo process.

Jose confirms this also (thanks).

Can you try filing in the attached UnixOSProcessAccessorgrimReaperProcess
and see if it helps? I do not know if it will make a difference, but the
idea is to put a timeout on the semaphore that is waiting for signals from
SIGCHLD. I am hoping that if these signals are sometimes being missed, then
the timeout will allow the process to recover from the problem.


 
 Interesting enough, the lock-up happens in a very specific place, a call 
 to git branch, which is a very short command returning just a few 
 characters (where all other commands have longuer outputs). Reducing the 
 frequency of the calls to git branch by a bit of caching reduces the 
 chances of a lock-up.


This is a good clue, and it may indicate a different kind of problem (so
maybe I am looking in the wrong place). Ben's suggestion of adding a delay
to the external process sounds like a good idea to help troubleshoot it.

Dave

 
'From Squeak4.5 of 30 May 2015 [latest update: #15039] on 2 June 2015 at 
9:35:21 pm'!

!UnixOSProcessAccessor methodsFor: 'initialize - release' stamp: 'dtl 6/2/2015 
20:54'!
grimReaperProcess
This is a process which waits for the death of a child OSProcess, and 
informs any dependents of the change. Use SIGCHLD events if possible,
otherwise a Delay to poll for exiting child processes.

| eventWaiter processSynchronizationDelay |
^ self canAccessSystem
ifTrue:
[eventWaiter := (self canAccessSystem and: [self 
canForwardExternalSignals])
ifTrue: [self sigChldSemaphore semaphore 
signaled by SIGCHLD ]
ifFalse: [Delay forMilliseconds: 200 simple 
polling loop ].
processSynchronizationDelay := Delay forMilliseconds: 
20.
grimReaper ifNil:
[grimReaper :=
[[(eventWaiter respondsTo: 
#waitTimeoutMSecs: )
ifTrue: [eventWaiter 
waitTimeoutMSecs: 1000 semaphore with timeout]
ifFalse: [eventWaiter wait].
processSynchronizationDelay wait. 
Avoids lost signals in heavy process switching
self changed: #childProcessStatus] 
repeat] newProcess.
grimReaper resume.
name selected to look reasonable in 
the process browser
grimReaper name: ((ReadStream on: 
grimReaper hash asString) next: 5)
, ': the child 
OSProcess watcher']]
ifFalse:
[nil]
! !

Re: [Pharo-users] Monticello / OS deadlock ?

[David T. Lewis]

On Tue, Jun 02, 2015 at 02:34:49PM +0200, Thierry Goubier wrote:
 2015-06-02 12:14 GMT+02:00 Jose San Leandro jose.sanlean...@osoco.es:
 
  Hi Thierry,
 
  ConfigurationOfOSProcess-ThierryGoubier.38.mcz, which corresponds to
  version 4.6.2.
 
 
 Ok, then this is the latest.
 
 
 
  Another workaround that would work for me is to be able to resume a
  previous load attempt of a Metacello project. Or a custom hook in
  Metacello to save the image after every dependency is successfully loaded.
 
 
 Yes, this would work. I'll ask again Dave if he has any idea; the bug is
 hard to reproduce.


Hi Thierry and Jose,

I am reading this thread with interest and will help if I can.

I do have one idea that we have not tried before. I have a theory that this may
be an intermittent problem caused by SIGCHLD signals (from the external OS 
process
when it exits) being missed by the UnixOSProcessAccessorgrimReaperProcess
that handles them.

If this is happening, then I may be able to change grimReaperProcess to
work around the problem.

When you see the OS deadlock condition, are you able tell if your Pharo VM
process has subprocesses in the zombie state (indicating that grimReaperProcess
did not clean them up)? The unix command ps -axf | less will let you look
at the process tree and that may give us a clue if this is happening.

Thanks!

Dave



 
 Would you mind telling the linux kernel / libc version of your gentoo box?
 
 Thierry
 
 
 
 
  2015-06-02 11:25 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com:
 
  Hi Jose,
 
  yes, I've noticed that as well. It was, at a point, drastic (i.e. almost
  allways lock-up) on my work development laptop; it now happens far less
  often (but it does happens to me from time to time).
 
  Dave Lewis, the author of OSProcess, fixed one issue which solved most of
  the lockups I had, but not all of them. The lockup is in the interaction
  between OSProcess inside Pharo and the external shell command (i.e. it
  concerns anything which uses OSProcess), and seems like missing a signal.
  It is also machine and linux version dependent (Ubuntu 14.10 was horrible,
  14.04 and 15.04 on the same hardware are far less sensitive), and seems to
  also depend on the load of the machine itself.
 
  By the way, which version of OSProcess you are using?
 
  Thierry
 
 
  2015-06-02 11:10 GMT+02:00 Jose San Leandro jose.sanlean...@osoco.es:
 
  Hi,
 
  In one of our projects we are using Pharo4. The image gets built by
  gradle, which loads the Metacello project. Sometimes, we see the build
  process hangs. It just don't progress.
 
  When adding local gitfiletree:// dependencies manually through
  Monticello after a while Pharo gets frozen. It's not always the same
  repository, it's not always the same number of repositories before it 
  hangs.
 
  I launched the image with strace, and attached gdb to the frozen process.
  It turns out It's waiting for a lock that gets never released.
 
  The environment is a 64b Gentoo Linux with enough of everything
  (multiple monitors, multiple cores, enough RAM).
 
  I hope anybody could point me how to dig deeper into this.
 
  # gdb
  (gdb) attach [pid]
  [..]
  Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols
  found)...done.
  Loaded symbols for /usr/lib32/libbz2.so.1
  0x0809d8bb in signalSemaphoreWithIndex ()
  (gdb) backtrace
  #0  0x0809d8bb in signalSemaphoreWithIndex ()
  #1  0x0810868c in handleSignal ()
  #2  signal handler called
  #3  0x0809d8c8 in signalSemaphoreWithIndex ()
  #4  0x0809f0af in aioPoll ()
  #5  0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from
  /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11
  #6  0x080a1887 in ioRelinquishProcessorForMicroseconds ()
  #7  0x080767fa in primitiveRelinquishProcessor ()
  #8  0xb6fc838c in ?? ()
  #9  0xb6fc3700 in ?? ()
  #10 0xb7952882 in ?? ()
  #11 0xb6fc3648 in ?? ()
  (gdb) disassemble
  Dump of assembler code for function handleSignal:
 0x081085e0 +0: sub$0x9c,%esp
 0x081085e6 +6: mov%ebx,0x90(%esp)
 0x081085ed +13:mov0xa0(%esp),%ebx
 0x081085f4 +20:mov%esi,0x94(%esp)
 0x081085fb +27:mov%edi,0x98(%esp)
 0x08108602 +34:movzbl 0x8168420(%ebx),%esi
 0x08108609 +41:mov%ebx,%eax
 0x0810860b +43:mov%esi,%edx
 0x0810860d +45:call   0x81070d0 forwardSignaltoSemaphoreAt
 0x08108612 +50:call   0x805aae0 pthread_self@plt
 0x08108617 +55:mov0x8168598,%edi
 0x0810861d +61:cmp%edi,%eax
 0x0810861f +63:je 0x8108680 handleSignal+160
 0x08108621 +65:lea0x10(%esp),%esi
 0x08108625 +69:mov%esi,(%esp)
 0x08108628 +72:call   0x805b330 sigemptyset@plt
 0x0810862d +77:mov%ebx,0x4(%esp)
 0x08108631 +81:mov%esi,(%esp)
 0x08108634 +84:call   0x805b0c0 sigaddset@plt
 0x08108639 +89:movl   $0x0,0x8(%esp)
 0x08108641 +97:mov

Re: [Pharo-users] OSProcess output to pharo

[David T. Lewis]

On Fri, May 01, 2015 at 09:04:59AM +0800, Pierce Ng wrote:
 On Tue, Apr 28, 2015 at 11:39:56AM -0400, David T. Lewis wrote:
  Yes, that is the correct way to do it.
 
 David,
 
 It seems Command Shell doesn't handle REPL applications like the sqlite3 
 shell,
 tclsh and goodsrv. How difficult is that to implement, in your view?
 Alternatively (unless they are the same stuff underneath) how to go about
 building something like Expect or pexpect?

Hi Pierce,

I'm not sure if I am understanding your question, but please have a
look at PipeableOSProcess classtkExample. This is an example of having
your image talking to a REPL shell, /usr/bin/wish in this case, but
probably similar to a sqlite3 shell. The wish shell is a tclsh interpreter
with Tk gui, so I expect that is close to what you are trying to do. 

If you are interested in having your squeak/pharo image be the REPL
server, then class ExternalCommmandShell may be closer to what you want.

Dave

Re: [Pharo-users] OSProcess output to pharo

[David T. Lewis]

Yes, that is the correct way to do it.

I think that the ConfigurationOfOSProcess for Pharo includes a portion of
the CommandShell package, so if you load OSProcess from that configuration
you should also get the necessary PipeableOSProcess. That said, I would
still encourage you to load the full CommandShell package and explore some
of the other things it it :-)

ConfigurationOfOSProcess and ConfigurationOfCommandShell have both been
recently updated for Pharo.

Dave


 Hi,

 I am doing some work with OSProcess and I want to get the output directly
 to pharo (i.e. a stream or a byteString would be cool).
 I have found this on the web
 http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/ where it's said
 that if you want access to the output you have to use PipeableOSProcess
 from CommandShell project.
 My question is: is still this the correct way to do it or meanwhile in
 OSProcess something was implemented to handle this specific case?

 Thanks.
 Cheers,
 Nicolas

Re: [Pharo-users] pharo headless and without gui. Seaside app

[David T. Lewis]

On Thu, Mar 12, 2015 at 06:23:28PM -0300, Pablo R. Digonzelli wrote:
 I think phil is right. -vm-display-null is the question . it aborts the 
 process. 
 Does not matter wich vm and image are you using. 
 For example i am trying pharo4 latest image latest vm. 

The -vm-display-null parameter is specific to Ian Piumarta's unix VM. It is
part of the loadable VM module system that he made for sound and displays.
You will find this in the various VMs that run on top of Ian platform code.
The Windows VMs originate from Andreas Raab's code base, which has different
VM command line parameters.

For common things like starting a headless VM, it would be a good idea to
make the command line parameters consistent across VMs. Maybe that could be
done most easily in the start scripts, as opposed to the VM executables.

Dave


 
 
 TIA 
 
 
 Ing. Pablo Digonzelli 
 Software Solutions 
 IP-Solutiones SRL 
 Metrotec SRL 
 25 de Mayo 521 
 San Miguel de Tucum??n 
 Email: pdigonze...@softsargentina.com 
 pdigonze...@gmail.com 
 Cel: 5493815982714 
 
 
 De: Esteban Lorenzano esteba...@gmail.com 
 Para: Any question about pharo is welcome pharo-users@lists.pharo.org 
 Enviados: Jueves, 12 de Marzo 2015 17:42:55 
 Asunto: Re: [Pharo-users] pharo headless and without gui. Seaside app 
 
 
 
 
 
 On 12 Mar 2015, at 21:23, p...@highoctane.be wrote: 
 
 
 
 Headless on windows is not working I think. 
 
 
 
 that???s not related, ???no-quit should be working (and ???headless should be 
 letting a window in the try). 
 
 can you provide more information? 
 
 vm version? 
 image version? 
 anything relevant? 
 
 just asking without information is like going to the doctor and just say 
 ???it hurts me?? not much we can do to help. 
 
 Esteban 
 
 
 BQ_BEGIN
 
 
 
 There is code in the VM but it looks more dead than alive. There is a console 
 version of Squeak and we may want to revive that. There us even code for a 
 Windows service in there... 
 
 Phil 
 Le 12 mars 2015 20:41, Pablo R. Digonzelli  pdigonze...@gmail.com  a 
 ??crit : 
 
 BQ_BEGIN
 
 Hi again, i cannot do it work for a windows 2012 server. it seems --no-quit 
 does not work . 
 Any suggestion? 
 
 
 TIA 
 
 
 Ing. Pablo Digonzelli 
 Software Solutions 
 IP-Solutiones SRL 
 Metrotec SRL 
 25 de Mayo 521 
 San Miguel de Tucum??n 
 Email: pdigonze...@softsargentina.com 
 pdigonze...@gmail.com 
 Cel: 5493815982714 
 
 
 De: Pablo Digonzelli  pdigonze...@gmail.com  
 Para: Any question about pharo is welcome  pharo-users@lists.pharo.org  
 Enviados: Jueves, 12 de Marzo 2015 16:20:08 
 Asunto: Re: [Pharo-users] pharo headless and without gui. Seaside app 
 
 Hi, i solve the problem! 
 
 ./pharo-vm/pharo -vm-display-null -vm-sound-null --plugins ./pharo-vm 
 --encoding utf8 imagefile.image --no-quit 
 
 works very well 
 
 TIA 
 
 
 Ing. Pablo Digonzelli 
 Software Solutions 
 IP-Solutiones SRL 
 Metrotec SRL 
 25 de Mayo 521 
 San Miguel de Tucum??n 
 Email: pdigonze...@softsargentina.com 
 pdigonze...@gmail.com 
 Cel: 5493815982714 
 
 
 De: pablo digonzelli  pdigonze...@softsargentina.dyndns.biz  
 Para: Any question about pharo is welcome  pharo-users@lists.pharo.org  
 Enviados: Jueves, 12 de Marzo 2015 15:47:49 
 Asunto: pharo headless and without gui. Seaside app 
 
 I need to run pharo headless and without gui for a Seaside app i am working 
 on. 
 I user pharo -vm-display-null --headless imagefile and does not work. 
 May be someone can help me. 
 TIA 
 
 
 Ing. Pablo Digonzelli 
 Software Solutions 
 IP-Solutiones SRL 
 Metrotec SRL 
 25 de Mayo 521 
 San Miguel de Tucum??n 
 Email: pdigonze...@softsargentina.com 
 pdigonze...@gmail.com 
 Cel: 5493815982714 
 
 
 BQ_END
 
 
 BQ_END
 
 
 

Re: [Pharo-users] any imap + smtp client available?

[David T. Lewis]

 Excerpts from David T. Lewis's message of 2015-01-26 13:58:16 +0100:
due to compute power constraints, i am running pharo as my only
application via xinit, having to constantly switch between pharo
and console (for mutt) is becoming painful.  :)
   another approach to that problem (which i am interested in) is to
 have a
   terminal within pharo.
 Are you aware of CommandShell (http://wiki.squeak.org/squeak/1914)? Look
 for
 ConfigurationOfCommandShell.

 well, PipeableOSProcess is part of the CommandShell package, so i have
 seen it
 and speculated that there was more to it, but i could not really see what
 else
 that was. thank you for pointing me to documentation. this will help for
 some
 of my commandline work. it won't help to run mutt, sup (the mail client i
 use)
 or tmux though.  for those a full terminal emulator is needed.

FYI, Ian Piumarta implemented telnet with full terminal (VT102) emulation.
It uses a pty interface and thus supports mutt and text editors directly
in the image.

  http://squeakvm.org/unix/goodies.html#html/goodies.m4.2.0

It works very well and does exactly what you want, but it was written more
than 10 years ago and I cannot say what would be required to make it work
on Pharo.

Dave

Re: [Pharo-users] NBSQLite3 on OS X - Pharo 3j

[David T. Lewis]

On Sun, Jan 25, 2015 at 09:54:12AM +0100, Sven Van Caekenberghe wrote:
 
  On 25 Jan 2015, at 07:13, Pierce Ng pie...@samadhiweb.com wrote:
  
  On OSX, OSProcessAccessor forThisOSProcess primGetCurrentWorkingDirectory
  gives /, while on Linux the same gives /home/pierce/work/pharo30. (Above
  requires the OSProcess package which is available from the Config Browser.)

That sounds right. It calls getcwd() from the VM process.

  primGetCurrentWorkingDirectory
  Call getcwd() to get the current working directory.

The current working directory of the VM process will (man 3 getcwd for
an exact description) will vary depending on how you launch the VM.

Dave

 
 Why not just use
 
   FileSystem disk workingDirectory 
 
 ?

Re: [Pharo-users] OSProcess command never ends

[David T. Lewis]

On Sun, Nov 02, 2014 at 05:54:32PM -0500, Offray Vladimir Luna C??rdenas wrote:
 Hi all.
 
 I'm having problems with OSProcess. When I run OSProcess command: 'my 
 command' on Linux, the Moose playground says that an 
 ExternalUnixOSProcess with pid 20887 on /bin/sh (running), but the 
 external process never ends. What I'm missing?
 

Hi Offray,

The most likely explanation is that the process is actually still running. 
Can you say what kind of program this is?

Dave

Re: [Pharo-users] OSProcess command never ends

[David T. Lewis]

On Sun, Nov 02, 2014 at 07:28:44PM -0500, Offray Vladimir Luna C??rdenas wrote:
 Thanks David and Juan,
 
 I was trying to run a pandoc conversion from markdown to html and I had 
 an error inside my command. Once corrected it works without any problem 
 and generates the desired file. One note on adding exec is that I get 
 this message on the playground:
 
 an ExternalUnixOSProcess with pid 21552 on /bin/sh (complete, normal 
 termination with status 0)
 
 which seems better. Despite of both working I will use the exec 
 suggestion to have a better message from external process.
 

Using the exec shell command is a good idea. Just for information, the
ExternalUnixOSProcess object is a proxy for the real external OS process,
which started by running the /bin/sh program. When you use exec to run
your pandoc program, the pandoc program will begin running in the same
external OS process that was originally running the /bin/sh program.
The ExternalUnixOSProcess object does not know that you did this, so it
still displays itself as an ExternalUnixOSProcess ... on /bin/sh even
though the OS process is now actually running your pandoc program instead.
But the exit status 0 came from your pandoc program, which is exactly
what you wanted.

Dave

Re: [Pharo-users] Booting into Pharo!

[David T. Lewis]

 On Sun, Sep 21, 2014 at 06:56:27PM -0400, David T. Lewis wrote:
 If you are booting directly into the image, you may find it useful to
 also
 load CommandShell/OSProcess into your image. This will let you open a
 Smalltalk shell window directly within your Squeak/Pharo boot image, so
 that you have access to the operating system with actually opening any
 windows or terminal sessions outside of your image.

   http://www.squeaksource.com/CommandShell
   http://www.squeaksource.com/OSProcess

 In view of ShellShock, from a PipeableOSProcess example:

   | env |
   env := OSProcess thisOSProcess environment copy.
   env at: #SHOCKED put: '() { :;}; echo ShellShocked;'.
   (PipeableOSProcess command: 'echo Nah environment: env) output

 This gives the following. (Yes, this is done on an unpatched bash for demo
 purposes. Everyone should patch as soon as you can.)

   ShellShocked
   Nah

 I have a webapp that shells out to some OS command line tool. I think I
 have
 written it such that untrustworthy web input does not taint the command
 line
 tool's environment and input. I think. Everyone doing similar may wish to
 relook at it.

 David, perhaps the code is already there, but can we run OS commands
 without
 invoking the shell?

 Pierce



Yes, you can run any executable command as an external OS process. It is
usually easier to run /bin/sh as the command and let the shell do the
parsing, but you can run any program you like. And you can also do the
shell in native Smalltalk with CommandShell, although this is not a
complete simulation of a unix shell, so sometimes it is better to use the
real /bin/sh program.

Dave

Re: [Pharo-users] Reading the last n lines from a file without using lots of memory

[David T. Lewis]

On Sat, Jun 28, 2014 at 08:19:41AM +0200, p...@highoctane.be wrote:
 Le 28 juin 2014 01:18, David T. Lewis le...@mail.msen.com a ??crit :
 
  On Fri, Jun 27, 2014 at 06:50:11PM +0200, p...@highoctane.be wrote:
   Thanks.
  
   But this would give me the 200 last chars. I am interested in the 200
 last
   lines.
  
   Now, I did this:
  
   command := 'tac ', file fullName, ' | head -200'.
   ^ (PipeableOSProcess command: command) output.
  
   which did the trick but isn't portable at all (Linux here).
 
  OT
  Don't forget to close the pipes on that PipeableOSProcess when you are
 done using it :-)
  /OT
 
 Isn't output closing them? Command is a complete string here.


No, one pipe handle will still be open. Use #closePipes to close it.

PipeableOSProcess is designed to participate in a pipeline of commands,
and in that environment each element of the pipeline is responsible for
closing the pipe from its predecessor.

Dave
 

Re: [Pharo-users] Reading the last n lines from a file without using lots of memory

[David T. Lewis]

On Fri, Jun 27, 2014 at 06:50:11PM +0200, p...@highoctane.be wrote:
 Thanks.
 
 But this would give me the 200 last chars. I am interested in the 200 last
 lines.
 
 Now, I did this:
 
 command := 'tac ', file fullName, ' | head -200'.
 ^ (PipeableOSProcess command: command) output.
 
 which did the trick but isn't portable at all (Linux here).

OT
Don't forget to close the pipes on that PipeableOSProcess when you are done 
using it :-)
/OT

Dave

[Pharo-users] OSProcess question (was: Omnibase)

[David T. Lewis]

On Fri, Jun 13, 2014 at 06:01:44PM -0700, Glenn Swanlund wrote:
 On Windows 7, I'm trying to install OmniBase in Pharo-30846. I get an error
 for  ExternalWindowsOSProcess  doesNotUnderstand defaultShellPath.
 
 Does anyone have a solution for this?

Hi Glenn,

Sorry I did not reply earlier. You are probably using an older version of 
OSProcess.
Sean DeNigris provided a fix for this problem, as well as some other Windows 
issues.
His updates were committed in the OSProcess repository:

Name: OSProcess-dtl.88
Author: dtl
Time: 29 December 2013, 1:47:22.224 pm
UUID: 12ce82c2-7d79-4af1-9e10-6f914757525e
Ancestors: OSProcess-dtl.87

OSProcess 4.5.11, CommandShell 4.6.8
Fixes by Sean DeNigris for win32 support in PipeableOSProcess (CommandShell 
package)

Date: Fri, 27 Dec 2013 10:09:37 -0800 (PST)
From: Sean P. DeNigris s...@clipperadams.com
To: squeak-...@lists.squeakfoundation.org
Subject: [squeak-dev] Fix: OSProcess on Windows
 
I made a small fix for MNU #defaultShellPath, which has been reported a few 
times. I didn't have repo write access, so I committed to
http://smalltalkhub.com/#!/~SeanDeNigris/SeansOutbox . Sometimes on Windows 
(e.g. seemingly when there are quoted command line arguments), the argument to 
#waitForCommand: and command: must be wrapped in $. I don't think there is any 
harm in always doing this (on Windows), but wanted to get feedback from Dave 
first...
 
OSProcess-Win32-SeanDeNigris.11
- Supply shell flags valid for Windows (i.e. '/c'); shell commands via
PipeableOSProcess are now working, with two restrictions:
- no access to stdout
- argument to #waitXyz: may have to be surroundedByDoubleQuotes
 
OSProcess-Base-SeanDeNigris.41
- Extract default shell flags ('-c') into a method, so that Windows may supply 
flags valid there (i.e. '/c')
 
CommandShell-Piping-SeanDeNigris.15
- Fix Win32 shell by providing path to cmd.exe

Re: [Pharo-users] Install Pharo on Win 7 64 bit computer

[David T. Lewis]

On Mon, Dec 23, 2013 at 06:52:25AM -0500, Daniel Roe wrote:
 I 
 am trying to install Pharo on a Win7 64 bit computer and am following the 
 examples given in the manual.
 
 I open up a new workspace and type in
 
 time now
 
 Then choose - print it - from the action menu and I get an error message 
 stating that the
 receiver of now is nil. i realize it's probably something really stupid I'm 
 missing but I need help please.

Hi Dan,

Try doing this again with upper-case 'T' like this:

  Time now

Explanation: There is a class in the system called 'Time'. That class is
an object (like everything else in the system), and the object knows
how to respond to the message called 'now'. When you evaluate the expression
'Time now' (by choosing print it in the workspace), the 'now' message is
sent to the 'Time' object, which responds with the current time.

What you saw instead was the result of sending the message 'now' to
an undefined variable 'time' in your workspace. Your 'now' message was
received by a special object called 'nil' that represents the undefined 
object. When the object called 'nil' received your 'now' message, it
generated the error message that you saw.

HTH,
Dave

Re: [Pharo-users] Process ID of VM

[David T. Lewis]

On Mon, Aug 19, 2013 at 11:02:37PM +0200, Udo Schneider wrote:
 All,
 
 is there anyway to get the PID of the VM running the image. I'm 
 searching for a way to differentiate different instances of the same 
 (read-only) image running on multiple VMs on the same server. Any other 
 thoughts?
 

If you have OSProcess:

  OSProcess thisOSProcess pid

Dave

Re: [Pharo-users] OSProcess execution from specific directory

[David T. Lewis]

On Mon, Aug 05, 2013 at 08:42:12AM -0400, Juraj Kubelka wrote:
 Hi!
 
 On execution of 
 
 (PipeableOSProcess command: 'pwd') output
 
 , it always says root directory (/). Is it possible to execute command from 
 specific directory? Or the only correct solution is like this?:
 
 (PipeableOSProcess command: 'cd /Users/jura/ ; pwd') output
 
 Thanks a lot.
 Cheers,
 Jura

By default, PipeableOSProcess classcommand: uses whatever current working
directory is being used by the VM (which may vary depending on how your
VM and image are being run). You can specify a different working directory
like this:

  (PipeableOSProcess command: 'pwd'
environment: nil
workingDir: '/usr/bin'
input: nil
output: nil
error: nil
errorPipelineStream: nil) output

HTH,
Dave