Smalltalk › Squeak › Squeak - Dev

OSProcess weirdness

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Jon Hylands

OSProcess weirdness

Hi everyone,

(I tried to send this message to David last night, but bounced, so I'm
reposting it to the list...)

I'm using OSProcess on my gumstix (Linux) to run some external commands
like ps, and it fails after the first command. I have tracked down the
reason it is failing, and it appears to be a bad lingering dependent for
the ThisOSProcessAccessor singleton.

I log the following when I start:

Starting server...
OSProcessAccessor forThisOSProcess: a UnixOSProcessAccessor on pid 2040
..dependents: #(a WindowsProcess with pid 2040 a UnixProcess with pid 2040)

So it looks like the release for dependents isn't working in
OSProcessAccessor >> #startUp:

I'm using OSProcess version 4.3.3 on Squeak 3.7, doing development on
Windows, and copying the image over to the gumstix to start it headless.

Any thoughts? Have you seen this before?

Later,
Jon

--------------------------------------------------------------
Jon Hylands [hidden email] http://www.huv.com/jon

Project: Micro Raptor (Small Biped Velociraptor Robot)
http://www.huv.com/blog

Jon Hylands

Re: OSProcess weirdness

On Wed, 28 Nov 2007 11:08:27 -0500, Jon Hylands <[hidden email]> wrote:

> So it looks like the release for dependents isn't working in
> OSProcessAccessor >> #startUp:

So, it looks like a bug. I changed: ThisOSProcess >> #initialize

It used to say:

processAccessor removeDependent: self.

and I changed it to say:

processAccessor breakDependents.

The problem is that if you're running on a different OS, the receiver is
not the dependent. The receiver is actually an instance of WindowsProcess
when the image is saved, but when it is resumed, it gets replaced by an
instance of UnixProcess. The process accessor has the windows process as a
dependent, so the removeDependent: call does nothing.

Hopefully David will read this and figure out how to fix it properly...

Later,
Jon

--------------------------------------------------------------
Jon Hylands [hidden email] http://www.huv.com/jon

Project: Micro Raptor (Small Biped Velociraptor Robot)
http://www.huv.com/blog

David T. Lewis

Re: OSProcess weirdness

On Wed, Nov 28, 2007 at 06:48:42PM -0500, Jon Hylands wrote:

> On Wed, 28 Nov 2007 11:08:27 -0500, Jon Hylands <[hidden email]> wrote:
>
> > So it looks like the release for dependents isn't working in
> > OSProcessAccessor >> #startUp:
>
> So, it looks like a bug. I changed: ThisOSProcess >> #initialize
>
> It used to say:
>
> processAccessor removeDependent: self.
>
> and I changed it to say:
>
> processAccessor breakDependents.
>
> The problem is that if you're running on a different OS, the receiver is
> not the dependent. The receiver is actually an instance of WindowsProcess
> when the image is saved, but when it is resumed, it gets replaced by an
> instance of UnixProcess. The process accessor has the windows process as a
> dependent, so the removeDependent: call does nothing.
>
> Hopefully David will read this and figure out how to fix it properly...

Hi Jon,

Thanks for the bug report and fix. I probably can't look into this for
a few days but will do so this weekend. I do recall that:

- Moving images between unix and windows is supposed to work. Maybe I
bolluxed something up in the more recent releases and forgot to test.

- As you noted, the singleton instance of the process accessor gets
replaced when you start the image on another platform. The fact that
you had an instance with dependents that were proxies for both unix
and windows external processes indicates that the replacement must not
have worked.

- I have had problems with loading new OSProcess versions on top of
old ones, with the resulting load not being properly initialized. If
this might be your situation, the easy fix is to remove OSProcess
from your image entirely and reload from SqueakMap/Universes. You may
have to stop and start your image once to get everything healthy.

- Other problems that I have encountered with moving images between
platforms and/or loading new versions of OSProcess on top of old ones
have to do with the grimReaperProcess getting messed up or terminated.
The process accessor singleton keeps this process running (look for
it in the process browser) to watch for child process exit events.
When an external child process exits, it signals a Squeak semaphore
(via the OSPP plugin) and the grimReaperProcess cleans up the external
process and updates the run state of its OS process proxy in the image.
If you are seeing OS processes (OSProcess thisOSProcess allMyChildren)
that never get to runState of #complete, then the grimReaper process
is probably tangled up in its shorts. Kill it and restart the image,
or reload OSProcess as per above.

Dave

Alexandre Rousseau

how to prevent TextMorph wrapping when entering contents that exceeds the morph's original bounds?

In reply to this post by Jon Hylands

How to I prevent an embedded TextMorph from wrapping the text I enter
into it if said text exceeds the current bounds of that morph,
despite the fact that its much-larger owner gives it ample expansion
room via the "hResizing: #spaceFill" selector?

I've tried a gazillion (minus one?) layout, autoFit, and wrapFlag
setting combos to no avail: that little son-of-a-... morph keeps
wrapping its text as soon as entry has exceeded the current bounds.

Thanks, again
Alex

Alexandre Rousseau

How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

In reply to this post by Jon Hylands

(I wasn't able to find a definitive answer on the newbies' list was
able to help; trying again on this one)

I have a RectangleMorph instance (used as a stickie note's title bar)
that contains 3 submorphs:

1. a SimpleButtonMorph, to trigger collapse/expansion of the stickie
note (collapsed = stickie note's editor submorph hidden)

2. a StringMorph that contains a summary -- a contracted copy -- of
the stickie note's editor's contents. I would like the length of that
summary to depend on the width of the stickie note's title bar.

3. a StringMorph instance that is set to the last modification date
of the stickie note.

So, question: how do I determine the maximum space that #2 can occupy
before provoking a resize of the stickie note, and given that stickie
note widths are left to user discretion, i.e., can and will vary.

Thanks
Alex

Edgar J. De Cleene

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

El 11/29/07 8:01 AM, "Alexandre Rousseau" <[hidden email]> escribió:

I following your previous post, trying to understand how should be
constructed your morph.

Until now, I think you wish some kind of Post It note, maybe I wrong.

> 1. a SimpleButtonMorph, to trigger collapse/expansion of the stickie
> note (collapsed = stickie note's editor submorph hidden)

Why not change collapsed/expanded state via click ?

> 2. a StringMorph that contains a summary -- a contracted copy -- of
> the stickie note's editor's contents. I would like the length of that
> summary to depend on the width of the stickie note's title bar.

I could use a ScrollableField instead, like in old versions of 3.10.
Now I embed into a SystemWindow as some like more .

> 3. a StringMorph instance that is set to the last modification date
> of the stickie note.
This is a very easy, you need a inst var like lastdate, and appropiate
senders and getters to #lastdate.

Then this should be a submorph, and the children morph have comeToFront in
his initialize

> So, question: how do I determine the maximum space that #2 can occupy
> before provoking a resize of the stickie note, and given that stickie
> note widths are left to user discretion, i.e., can and will vary.

If you send a example of full text, contracted text, maybe more help come.

Edgar

Alexandre Rousseau

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

Hi Edgar

> I following your previous post, trying to understand how should be
> constructed your morph.
>
> Until now, I think you wish some kind of Post It note, maybe I wrong.
>

Yes, and that's working fine, for the most part (see attached
screenshot: note.gif).

>> 1. a SimpleButtonMorph, to trigger collapse/expansion of the stickie
>> note (collapsed = stickie note's editor submorph hidden)
>
> Why not change collapsed/expanded state via click ?
>
Personal preference, but regardless of how, collapse works too. See
note-collapsed.gif.

As you can see from the screenshot, the collapsed note contains a
summary of its contents, obtained until now with this:

NPNote>>updateSummaryLabel
self contents ifNotNil:
[(self summaryMorph)
contents: (self contents asString withSeparatorsCompacted
contractTo: (32 min: self contents size "NEED TO CHANGE THIS
CODE"))]

What I would want to do instead is be able to get the maximum string
length that my summary can be set to without triggering a resize of
the title bar, hence the note. Right now, if I widen my note (via the
halo), my summary does not fill the title bar, i.e., note-collapsed-
wide.gif:

I am not sure if this is clear enough. Also, I hope the size of this
email (20K) doesn't cause too much trouble.

Thanks
Alex

>> 2. a StringMorph that contains a summary -- a contracted copy -- of
>> the stickie note's editor's contents. I would like the length of that
>> summary to depend on the width of the stickie note's title bar.
>
> I could use a ScrollableField instead, like in old versions of 3.10.
> Now I embed into a SystemWindow as some like more .
>
>> 3. a StringMorph instance that is set to the last modification date
>> of the stickie note.
> This is a very easy, you need a inst var like lastdate, and appropiate
> senders and getters to #lastdate.
>
> Then this should be a submorph, and the children morph have
> comeToFront in
> his initialize
>
>> So, question: how do I determine the maximum space that #2 can occupy
>> before provoking a resize of the stickie note, and given that stickie
>> note widths are left to user discretion, i.e., can and will vary.
>
> If you send a example of full text, contracted text, maybe more
> help come.
>
> Edgar
>
>
>

note.gif (4K) Download Attachment

note-collapsed.gif (2K) Download Attachment

note-collapsed-wide.gif (3K) Download Attachment

Edgar J. De Cleene

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

El 11/29/07 10:03 AM, "Alexandre Rousseau" <[hidden email]> escribió:

> Hi Edgar
>
>
>> I following your previous post, trying to understand how should be
>> constructed your morph.
>>
>> Until now, I think you wish some kind of Post It note, maybe I wrong.
>>
>
>
> Yes, and that's working fine, for the most part (see attached
> screenshot: note.gif).
> ?
> ?
> ?
>
>>> 1. a SimpleButtonMorph, to trigger collapse/expansion of the stickie
>>> note (collapsed = stickie note's editor submorph hidden)
>>
>> Why not change collapsed/expanded state via click ?
>>
> Personal preference, but regardless of how, collapse works too. See
> note-collapsed.gif.
> ?
> ?
> ?
>
> As you can see from the screenshot, the collapsed note contains a
> summary of its contents, obtained until now with this:
>
> NPNote>>updateSummaryLabel
> self contents ifNotNil:
> [(self summaryMorph)
> contents: (self contents asString withSeparatorsCompacted
> contractTo: (32 min: self contents size "NEED TO CHANGE THIS
> CODE"))]
>
> What I would want to do instead is be able to get the maximum string
> length that my summary can be set to without triggering a resize of
> the title bar, hence the note. Right now, if I widen my note (via the
> halo), my summary does not fill the title bar, i.e., note-collapsed-
> wide.gif:
> ?
> ?
> ?
>
>
> I am not sure if this is clear enough. Also, I hope the size of this
> email (20K) doesn't cause too much trouble.
>
> Thanks
> Alex
>
>
>
>>> 2. a StringMorph that contains a summary -- a contracted copy -- of
>>> the stickie note's editor's contents. I would like the length of that
>>> summary to depend on the width of the stickie note's title bar.
>>
>> I could use a ScrollableField instead, like in old versions of 3.10.
>> Now I embed into a SystemWindow as some like more .
>>
>>> 3. a StringMorph instance that is set to the last modification date
>>> of the stickie note.
>> This is a very easy, you need a inst var like lastdate, and appropiate
>> senders and getters to #lastdate.
>>
>> Then this should be a submorph, and the children morph have
>> comeToFront in
>> his initialize
>>
>>> So, question: how do I determine the maximum space that #2 can occupy
>>> before provoking a resize of the stickie note, and given that stickie
>>> note widths are left to user discretion, i.e., can and will vary.
>>
>> If you send a example of full text, contracted text, maybe more
>> help come.
>>
>> Edgar

>>
Alexandre :

Very clear now, and you could put any pict as attached.
The max size on this list is 100 k on newbies is only 40 k.
The most easy way is changing name overriding #collapse , as you could see
in this very quick and dirty using current "history of 3.10 " as example.
You could see what if I change arbritray the name to "Pepe", the collapsed
label shows only this four letters.

If still unclear, send new mail.

Edgar

Picture 3.png (62K) Download Attachment

Alexandre Rousseau

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

Hi Edgar

Thanks very much. But what imagine that:

1. my text is much longer, say, 'A test is a test is a test is a test
is a test is a test is a test is a test is a test is a test is a test
is a test.'
2. the user has not yet resized my collapsed morph. Contents are
contracted to, say, 32 characters, and copied to the title bar. So
far, so good.
3. next, the user resizes the collapsed morph so that its length is
twice what it was in #2. I would then want to be able to see more
characters in that title bar, say, 64.

Actually, playing with ProjectViewMorphs, I see the behaviour I need.
Say you name a project with a ridiculously long name. Collapsing the
project view (in place) reveals only parts of the long title.
Resizing it reveals or hides characters as needed.

Somehow, I can't get this to happen with my own collapsed morph.
Delving into the ProjectViewMorph class does not shed much light on
why this is happening, but I suspect that that project view's
AlignmentMorph row plays a role in this. I'll do some tests.

Thanks for your help, again
Alex

On 29-Nov-07, at 9:43 PM, Edgar J. De Cleene wrote:

>
>
>
> El 11/29/07 10:03 AM, "Alexandre Rousseau" <[hidden email]>
> escribió:
>
>> Hi Edgar
>>
>>
>>> I following your previous post, trying to understand how should be
>>> constructed your morph.
>>>
>>> Until now, I think you wish some kind of Post It note, maybe I
>>> wrong.
>>>
>>
>>
>> Yes, and that's working fine, for the most part (see attached
>> screenshot: note.gif).
>> ?
>> ?
>> ?
>>
>>>> 1. a SimpleButtonMorph, to trigger collapse/expansion of the
>>>> stickie
>>>> note (collapsed = stickie note's editor submorph hidden)
>>>
>>> Why not change collapsed/expanded state via click ?
>>>
>> Personal preference, but regardless of how, collapse works too. See
>> note-collapsed.gif.
>> ?
>> ?
>> ?
>>
>> As you can see from the screenshot, the collapsed note contains a
>> summary of its contents, obtained until now with this:
>>
>> NPNote>>updateSummaryLabel
>> self contents ifNotNil:
>> [(self summaryMorph)
>> contents: (self contents asString withSeparatorsCompacted
>> contractTo: (32 min: self contents size "NEED TO CHANGE THIS
>> CODE"))]
>>
>> What I would want to do instead is be able to get the maximum string
>> length that my summary can be set to without triggering a resize of
>> the title bar, hence the note. Right now, if I widen my note (via the
>> halo), my summary does not fill the title bar, i.e., note-collapsed-
>> wide.gif:
>> ?
>> ?
>> ?
>>
>>
>> I am not sure if this is clear enough. Also, I hope the size of this
>> email (20K) doesn't cause too much trouble.
>>
>> Thanks
>> Alex
>>
>>
>>
>>>> 2. a StringMorph that contains a summary -- a contracted copy -- of
>>>> the stickie note's editor's contents. I would like the length of
>>>> that
>>>> summary to depend on the width of the stickie note's title bar.
>>>
>>> I could use a ScrollableField instead, like in old versions of 3.10.
>>> Now I embed into a SystemWindow as some like more .
>>>
>>>> 3. a StringMorph instance that is set to the last modification date
>>>> of the stickie note.
>>> This is a very easy, you need a inst var like lastdate, and
>>> appropiate
>>> senders and getters to #lastdate.
>>>
>>> Then this should be a submorph, and the children morph have
>>> comeToFront in
>>> his initialize
>>>
>>>> So, question: how do I determine the maximum space that #2 can
>>>> occupy
>>>> before provoking a resize of the stickie note, and given that
>>>> stickie
>>>> note widths are left to user discretion, i.e., can and will vary.
>>>
>>> If you send a example of full text, contracted text, maybe more
>>> help come.
>>>
>>> Edgar
>
>
>
>>>
> Alexandre :
>
> Very clear now, and you could put any pict as attached.
> The max size on this list is 100 k on newbies is only 40 k.
> The most easy way is changing name overriding #collapse , as you
> could see
> in this very quick and dirty using current "history of 3.10 " as
> example.
> You could see what if I change arbritray the name to "Pepe", the
> collapsed
> label shows only this four letters.
>
> If still unclear, send new mail.
>
>
> Edgar
>
> <Picture 3.png>

Edgar J. De Cleene

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

El 11/29/07 11:48 AM, "Alexandre Rousseau" <[hidden email]> escribió:

> Hi Edgar
>
> Thanks very much. But what imagine that:
>
> 1. my text is much longer, say, 'A test is a test is a test is a test
> is a test is a test is a test is a test is a test is a test is a test
> is a test.'
> 2. the user has not yet resized my collapsed morph. Contents are
> contracted to, say, 32 characters, and copied to the title bar. So
> far, so good.
> 3. next, the user resizes the collapsed morph so that its length is
> twice what it was in #2. I would then want to be able to see more
> characters in that title bar, say, 64.
>
> Actually, playing with ProjectViewMorphs, I see the behaviour I need.
> Say you name a project with a ridiculously long name. Collapsing the
> project view (in place) reveals only parts of the long title.
> Resizing it reveals or hides characters as needed.
>
> Somehow, I can't get this to happen with my own collapsed morph.
> Delving into the ProjectViewMorph class does not shed much light on
> why this is happening, but I suspect that that project view's
> AlignmentMorph row plays a role in this. I'll do some tests.
>
> Thanks for your help, again
> Alex

Good refining.
So tomorrow I try to dig on ProjectViewMorphs for find the methods.
If/When , I send more mail, if you find first, do some recipe in swiki for
next guy.

Edgar

Karl-19

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

In reply to this post by Alexandre Rousseau

Alexandre Rousseau wrote:

> Hi Edgar
>
> Thanks very much. But what imagine that:
>
> 1. my text is much longer, say, 'A test is a test is a test is a test
> is a test is a test is a test is a test is a test is a test is a test
> is a test.'
> 2. the user has not yet resized my collapsed morph. Contents are
> contracted to, say, 32 characters, and copied to the title bar. So
> far, so good.
> 3. next, the user resizes the collapsed morph so that its length is
> twice what it was in #2. I would then want to be able to see more
> characters in that title bar, say, 64.
>
> Actually, playing with ProjectViewMorphs, I see the behaviour I need.
> Say you name a project with a ridiculously long name. Collapsing the
> project view (in place) reveals only parts of the long title. Resizing
> it reveals or hides characters as needed.
>
> Somehow, I can't get this to happen with my own collapsed morph.
> Delving into the ProjectViewMorph class does not shed much light on
> why this is happening, but I suspect that that project view's
> AlignmentMorph row plays a role in this. I'll do some tests.

The behavior you describe is in the label part of a SystemWindow.
Karl

>
> Thanks for your help, again
> Alex
>
>
>
> On 29-Nov-07, at 9:43 PM, Edgar J. De Cleene wrote:
>
>>
>>
>>
>> El 11/29/07 10:03 AM, "Alexandre Rousseau" <[hidden email]>
>> escribió:
>>
>>> Hi Edgar
>>>
>>>
>>>> I following your previous post, trying to understand how should be
>>>> constructed your morph.
>>>>
>>>> Until now, I think you wish some kind of Post It note, maybe I wrong.
>>>>
>>>
>>>
>>> Yes, and that's working fine, for the most part (see attached
>>> screenshot: note.gif).
>>> ?
>>> ?
>>> ?
>>>
>>>>> 1. a SimpleButtonMorph, to trigger collapse/expansion of the stickie
>>>>> note (collapsed = stickie note's editor submorph hidden)
>>>>
>>>> Why not change collapsed/expanded state via click ?
>>>>
>>> Personal preference, but regardless of how, collapse works too. See
>>> note-collapsed.gif.
>>> ?
>>> ?
>>> ?
>>>
>>> As you can see from the screenshot, the collapsed note contains a
>>> summary of its contents, obtained until now with this:
>>>
>>> NPNote>>updateSummaryLabel
>>> self contents ifNotNil:
>>> [(self summaryMorph)
>>> contents: (self contents asString withSeparatorsCompacted
>>> contractTo: (32 min: self contents size "NEED TO CHANGE THIS
>>> CODE"))]
>>>
>>> What I would want to do instead is be able to get the maximum string
>>> length that my summary can be set to without triggering a resize of
>>> the title bar, hence the note. Right now, if I widen my note (via the
>>> halo), my summary does not fill the title bar, i.e., note-collapsed-
>>> wide.gif:
>>> ?
>>> ?
>>> ?
>>>
>>>
>>> I am not sure if this is clear enough. Also, I hope the size of this
>>> email (20K) doesn't cause too much trouble.
>>>
>>> Thanks
>>> Alex
>>>
>>>
>>>
>>>>> 2. a StringMorph that contains a summary -- a contracted copy -- of
>>>>> the stickie note's editor's contents. I would like the length of that
>>>>> summary to depend on the width of the stickie note's title bar.
>>>>
>>>> I could use a ScrollableField instead, like in old versions of 3.10.
>>>> Now I embed into a SystemWindow as some like more .
>>>>
>>>>> 3. a StringMorph instance that is set to the last modification date
>>>>> of the stickie note.
>>>> This is a very easy, you need a inst var like lastdate, and appropiate
>>>> senders and getters to #lastdate.
>>>>
>>>> Then this should be a submorph, and the children morph have
>>>> comeToFront in
>>>> his initialize
>>>>
>>>>> So, question: how do I determine the maximum space that #2 can occupy
>>>>> before provoking a resize of the stickie note, and given that stickie
>>>>> note widths are left to user discretion, i.e., can and will vary.
>>>>
>>>> If you send a example of full text, contracted text, maybe more
>>>> help come.
>>>>
>>>> Edgar
>>
>>
>>
>>>>
>> Alexandre :
>>
>> Very clear now, and you could put any pict as attached.
>> The max size on this list is 100 k on newbies is only 40 k.
>> The most easy way is changing name overriding #collapse , as you
>> could see
>> in this very quick and dirty using current "history of 3.10 " as
>> example.
>> You could see what if I change arbritray the name to "Pepe", the
>> collapsed
>> label shows only this four letters.
>>
>> If still unclear, send new mail.
>>
>>
>> Edgar
>>
>> <Picture 3.png>
>
>
>

Alexandre Rousseau

Re: How do I find out the maximum extent that a morph can be set to, without this impacting the current extent of its owner morph?

In reply to this post by Edgar J. De Cleene

I will. Thanks. A.

On 30-Nov-07, at 2:02 AM, Edgar J. De Cleene wrote:

>
>
>
> El 11/29/07 11:48 AM, "Alexandre Rousseau" <[hidden email]>
> escribió:
>
>> Hi Edgar
>>
>> Thanks very much. But what imagine that:
>>
>> 1. my text is much longer, say, 'A test is a test is a test is a test
>> is a test is a test is a test is a test is a test is a test is a test
>> is a test.'
>> 2. the user has not yet resized my collapsed morph. Contents are
>> contracted to, say, 32 characters, and copied to the title bar. So
>> far, so good.
>> 3. next, the user resizes the collapsed morph so that its length is
>> twice what it was in #2. I would then want to be able to see more
>> characters in that title bar, say, 64.
>>
>> Actually, playing with ProjectViewMorphs, I see the behaviour I need.
>> Say you name a project with a ridiculously long name. Collapsing the
>> project view (in place) reveals only parts of the long title.
>> Resizing it reveals or hides characters as needed.
>>
>> Somehow, I can't get this to happen with my own collapsed morph.
>> Delving into the ProjectViewMorph class does not shed much light on
>> why this is happening, but I suspect that that project view's
>> AlignmentMorph row plays a role in this. I'll do some tests.
>>
>> Thanks for your help, again
>> Alex
>
>
> Good refining.
> So tomorrow I try to dig on ProjectViewMorphs for find the methods.
> If/When , I send more mail, if you find first, do some recipe in
> swiki for
> next guy.
>
> Edgar
>
>
>

Jon Hylands

Re: OSProcess weirdness

In reply to this post by David T. Lewis

On Wed, 28 Nov 2007 23:34:23 -0500, "David T. Lewis" <[hidden email]>
wrote:

> Thanks for the bug report and fix. I probably can't look into this for
> a few days but will do so this weekend.

David,

I see you posted a new version of OSCommandShell - did you ever get
anywhere with this bug in OSProcess?

Later,
Jon

--------------------------------------------------------------
Jon Hylands [hidden email] http://www.huv.com/jon

Project: Micro Raptor (Small Biped Velociraptor Robot)
http://www.huv.com/blog

David T. Lewis

Re: OSProcess weirdness

On Sun, Dec 23, 2007 at 08:37:09AM -0500, Jon Hylands wrote:

> On Wed, 28 Nov 2007 23:34:23 -0500, "David T. Lewis" <[hidden email]>
> wrote:
>
> > Thanks for the bug report and fix. I probably can't look into this for
> > a few days but will do so this weekend.
>
> David,
>
> I see you posted a new version of OSCommandShell - did you ever get
> anywhere with this bug in OSProcess?

Jon,

Sorry, I dropped the ball on this. I just added your patch to a new
version (OSProcess 4.3.6) on SqueakMap. I suspect that the problem
you were having moving images between Windows and Unix may have been
due to leftover cruft from an older OSProcess. I'm using Montecello
(in the SARs) now, so this should get cleaned up whenever you reload
a new OSP version. Either way, OSP 4.3.6 will hopefully take care
of the problem. Unfortunately I don't have time to test moving images
back and forth to Windows right now, so please let me know if this
does not take care of the problem.

Dave