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 
> wrote:
>
>> Hi Mariano,
>>
>> 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck
>> :
>> >
>> >
>> > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris
>> 
>> > 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] [Ann] OSSubprocess 1.0.0

[Mariano Martinez Peck]

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 
wrote:

> Hi Mariano,
>
> 2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck :
> >
> >
> > On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris 
> > 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] GIFReadWriter and Animated GIFs

[Eric Gade]

Thanks, Sven. I'll switch over to Pharo 7a and continue my efforts there.
When I have something worth a damn I'll submit a PR according to the new
contribution protocol.

On Wed, May 23, 2018 at 4:44 PM, Sven Van Caekenberghe  wrote:

> Hi Eric,
>
> I can't speak about the Morph related aspects, not my area of expertise.
>
> The other aspects, about the actual read/writer, all sound reasonable.
>
> It would be very good if someone contributed to improve the quality of
> GIFReadWriter, thanks for doing this !
>
> One remark though, I think that your changes are based off Pharo 6. That
> is a problem because GIFReadWriter underwent a couple of changes in
> relation to stream/file handling. I see some small conflicts in
> #readHeader, nothing major.
>
> I also assume the transcript printing will be removed eventually.
>
> Normally development takes place in Pharo 7 with an option to back port to
> Pharo 6.1 if it is a very important change. These kind of discussions also
> normally happen on the pharo-dev mailing list.
>
> Thanks again and please continue.
>
> Sven
>
> PS: maybe you can find a GIF test suite somewhere like there exists one
> for PNG (https://pharo.manuscript.com/f/cases/21927/Figure-out-why-
> PNGReadWriter-does-not-pass-a-full-test-suite and https://github.com/
> DraagrenKirneh/PngSuiteExplorer).
>
> > On 23 May 2018, at 21:08, Eric Gade  wrote:
> >
> > Hello all,
> >
> > Please excuse the length of this email.
> >
> > A week or two ago I discovered that the GIF implementation in Pharo (and
> possibly Squeak?) is incomplete. This has two side effects:
> > 1) Not all GIF data will load correctly;
> > 2) There is for now no way to display animated GIFs.
> >
> > It looks like the corresponding classes have not been updated since the
> 90s.
> >
> > But fear not! I've been working on a solution, and need the community's
> feedback and advice.
> >
> > # The Problem with GIFs #
> > One of the issues here is that GIF files can (and do) contain multiple
> images inside of them. The root header will supply things like a "screen
> size" in which these nested images should be displayed. That also means
> that each nested image does not have to have the same dimensions as the
> parent object -- in fact, most are offset somewhere inside of the "screen."
> >
> > Additionally, each nested image will contain information about how it
> should be handled when animating. This is a crucial point. In many cases
> images are just updates of a small area that should be applied to the
> previous image in the set. GIFs call this attribute the "disposal," and
> this information is contained in a packed byte.
> >
> > Both GIFReadWriter and AnimatedGIFReadWriter have intentionally
> skipped/ignored the bits/bytes that store and keep track of these things.
> GIFReadWriter on its own will only read the first Form and does not store
> information about disposal, offsets, etc. These classes are not reading all
> the information we need to display GIFs!
> >
> > # My Solution #
> > The attached changes file includes some preliminary updates to the
> GIFReadWriter class. Now when each nested image is read, it will be loaded
> into a collection called "frames" as a (new -- see attached package file)
> AnimatedImageFrame. Instances of this new class will store the disposal
> symbol, offset, and form for each nested image in the file.
> >
> > I have also created an AnimatedImageMorph which reads AnimatedImageFrame
> objects and cycles them based on the disposal re-drawing rules.
> >
> > # Trying This Out #
> > To try this out, first load the attached changes file and the ST file.
> >
> > You'll need a FileReference to a gif file, so when you have one execute
> the following:
> >
> > ```smalltalk
> > file := "your gif filereference here"
> > img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter
> formsFromStream: file readStream).
> > img openInWorld.
> > ```
> >
> > # Issues #
> > Not all GIF images work. This has to do with my implementation of the
> disposal (redrawing) rules for each frame. I'm still experimenting.
> >
> > I believe AnimatedGIFReadWriter should be deprecated and all appropriate
> functionality should be put into GIFReadWriter. If you all agree, I will
> make several changes to GIFReadWriter that I think will be helpful /
> necessary.
> >
> > AnimatedImageMorph is also incomplete. I'm not sure if I should subclass
> ImageMorph for this or not.
> >
> > # Your Feedback #
> > If you disagree with any point of this architecture, please let me know.
> Also if you come across GIFs that do not animate or display properly, send
> them my way please!
> >
> > --
> > Eric
> > 
>
>
>


-- 
Eric

Re: [Pharo-users] GIFReadWriter and Animated GIFs

[Sven Van Caekenberghe]

Hi Eric,

I can't speak about the Morph related aspects, not my area of expertise.

The other aspects, about the actual read/writer, all sound reasonable.

It would be very good if someone contributed to improve the quality of 
GIFReadWriter, thanks for doing this !

One remark though, I think that your changes are based off Pharo 6. That is a 
problem because GIFReadWriter underwent a couple of changes in relation to 
stream/file handling. I see some small conflicts in #readHeader, nothing major.

I also assume the transcript printing will be removed eventually.

Normally development takes place in Pharo 7 with an option to back port to 
Pharo 6.1 if it is a very important change. These kind of discussions also 
normally happen on the pharo-dev mailing list.

Thanks again and please continue.

Sven

PS: maybe you can find a GIF test suite somewhere like there exists one for PNG 
(https://pharo.manuscript.com/f/cases/21927/Figure-out-why-PNGReadWriter-does-not-pass-a-full-test-suite
 and https://github.com/DraagrenKirneh/PngSuiteExplorer).

> On 23 May 2018, at 21:08, Eric Gade  wrote:
> 
> Hello all,
> 
> Please excuse the length of this email.
> 
> A week or two ago I discovered that the GIF implementation in Pharo (and 
> possibly Squeak?) is incomplete. This has two side effects:
> 1) Not all GIF data will load correctly;
> 2) There is for now no way to display animated GIFs.
> 
> It looks like the corresponding classes have not been updated since the 90s.
> 
> But fear not! I've been working on a solution, and need the community's 
> feedback and advice.
> 
> # The Problem with GIFs #
> One of the issues here is that GIF files can (and do) contain multiple images 
> inside of them. The root header will supply things like a "screen size" in 
> which these nested images should be displayed. That also means that each 
> nested image does not have to have the same dimensions as the parent object 
> -- in fact, most are offset somewhere inside of the "screen."
> 
> Additionally, each nested image will contain information about how it should 
> be handled when animating. This is a crucial point. In many cases images are 
> just updates of a small area that should be applied to the previous image in 
> the set. GIFs call this attribute the "disposal," and this information is 
> contained in a packed byte.
> 
> Both GIFReadWriter and AnimatedGIFReadWriter have intentionally 
> skipped/ignored the bits/bytes that store and keep track of these things. 
> GIFReadWriter on its own will only read the first Form and does not store 
> information about disposal, offsets, etc. These classes are not reading all 
> the information we need to display GIFs!
>   
> # My Solution #
> The attached changes file includes some preliminary updates to the 
> GIFReadWriter class. Now when each nested image is read, it will be loaded 
> into a collection called "frames" as a (new -- see attached package file) 
> AnimatedImageFrame. Instances of this new class will store the disposal 
> symbol, offset, and form for each nested image in the file.
> 
> I have also created an AnimatedImageMorph which reads AnimatedImageFrame 
> objects and cycles them based on the disposal re-drawing rules.
>   
> # Trying This Out #
> To try this out, first load the attached changes file and the ST file. 
>   
> You'll need a FileReference to a gif file, so when you have one execute the 
> following:
> 
> ```smalltalk
> file := "your gif filereference here"
> img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter 
> formsFromStream: file readStream).
> img openInWorld.
> ```
> 
> # Issues #
> Not all GIF images work. This has to do with my implementation of the 
> disposal (redrawing) rules for each frame. I'm still experimenting.
> 
> I believe AnimatedGIFReadWriter should be deprecated and all appropriate 
> functionality should be put into GIFReadWriter. If you all agree, I will make 
> several changes to GIFReadWriter that I think will be helpful / necessary.
> 
> AnimatedImageMorph is also incomplete. I'm not sure if I should subclass 
> ImageMorph for this or not.
> 
> # Your Feedback #
> If you disagree with any point of this architecture, please let me know. Also 
> if you come across GIFs that do not animate or display properly, send them my 
> way please!
> 
> -- 
> Eric
> 

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

[Thierry Goubier]

Hi Mariano,

2018-05-23 19:57 GMT+02:00 Mariano Martinez Peck :
>
>
> On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris 
> 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

[Pharo-users] GIFReadWriter and Animated GIFs

[Eric Gade]

Hello all,

Please excuse the length of this email.

A week or two ago I discovered that the GIF implementation in Pharo (and
possibly Squeak?) is incomplete. This has two side effects:
1) Not all GIF data will load correctly;
2) There is for now no way to display animated GIFs.

It looks like the corresponding classes have not been updated since the 90s.

But fear not! I've been working on a solution, and need the community's
feedback and advice.

# The Problem with GIFs #
One of the issues here is that GIF files can (and do) contain multiple
images inside of them. The root header will supply things like a "screen
size" in which these nested images should be displayed. That also means
that each nested image does not have to have the same dimensions as the
parent object -- in fact, most are offset somewhere inside of the "screen."

Additionally, each nested image will contain information about how it
should be handled when animating. This is a crucial point. In many cases
images are just updates of a small area that should be applied to the
previous image in the set. GIFs call this attribute the "disposal," and
this information is contained in a packed byte.

Both GIFReadWriter and AnimatedGIFReadWriter have intentionally
skipped/ignored the bits/bytes that store and keep track of these things.
GIFReadWriter on its own will only read the first Form and does not store
information about disposal, offsets, etc. These classes are not reading all
the information we need to display GIFs!

# My Solution #
The attached changes file includes some preliminary updates to the
GIFReadWriter class. Now when each nested image is read, it will be loaded
into a collection called "frames" as a (new -- see attached package file)
AnimatedImageFrame. Instances of this new class will store the disposal
symbol, offset, and form for each nested image in the file.

I have also created an AnimatedImageMorph which reads AnimatedImageFrame
objects and cycles them based on the disposal re-drawing rules.

# Trying This Out #
To try this out, first load the attached changes file and the ST file.

You'll need a FileReference to a gif file, so when you have one execute the
following:

```smalltalk
file := "your gif filereference here"
img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter
formsFromStream: file readStream).
img openInWorld.
```

# Issues #
Not all GIF images work. This has to do with my implementation of the
disposal (redrawing) rules for each frame. I'm still experimenting.

I believe AnimatedGIFReadWriter should be deprecated and all appropriate
functionality should be put into GIFReadWriter. If you all agree, I will
make several changes to GIFReadWriter that I think will be helpful /
necessary.

AnimatedImageMorph is also incomplete. I'm not sure if I should subclass
ImageMorph for this or not.

# Your Feedback #
If you disagree with any point of this architecture, please let me know.
Also if you come across GIFs that do not animate or display properly, send
them my way please!

-- 
Eric


Images-Animated.st
Description: Binary data
'From Pharo6.0 of 13 May 2016 [Latest update: #60540] on 23 May 2018 at 11:28:36.06927 am'!
ImageReadWriter subclass: #GIFReadWriter
	instanceVariableNames: 'width height bitsPerPixel colorPalette rowByteSize xpos ypos pass interlace codeSize clearCode eoiCode freeCode maxCode prefixTable suffixTable remainBitCount bufByte bufStream transparentIndex mapOf32 localColorTable delay loopCount offset frames canvasWidth canvasHeight backgroundColorIndex'
	classVariableNames: 'Extension ImageSeparator Terminator'
	poolDictionaries: ''
	category: 'Graphics-Files'!

!GIFReadWriter methodsFor: 'private-decoding' stamp: 'EricGade 5/18/2018 17:36'!
readHeader
	| is89 byte hasColorMap |
	frames := OrderedCollection new. "For storing AnimatedImageFrames"
	(self hasMagicNumber: 'GIF87a' asByteArray) 
		ifTrue: [ is89 := false ]
		ifFalse: 
			[ (self hasMagicNumber: 'GIF89a' asByteArray) 
ifTrue: [ is89 := true ]
ifFalse: [ ^ self error: 'This does not appear to be a GIF file' ] ].
	"Width and Height for whole canvas, not
	just an invididual frame/form"
	canvasWidth := self readWord.
	canvasHeight := self readWord.
	byte := self next.
	hasColorMap := (byte bitAnd: 128) ~= 0.
	bitsPerPixel := (byte bitAnd: 7) + 1.
	backgroundColorIndex := self next.
	self next ~= 0 ifTrue: 
		[ is89 ifFalse: [ ^ self error: 'corrupt GIF file (screen descriptor)' ] ].
	hasColorMap 
		ifTrue: [ colorPalette := self readColorTable: (1 bitShift: bitsPerPixel) ]
		ifFalse: 
			[ "Transcript cr; show: 'GIF file does not have a color map.'."
			colorPalette := nil	"Palette monochromeDefault" ]! !

!GIFReadWriter methodsFor: 'private-decoding' stamp: 'EricGade 5/18/2018 16:04'!
readBody
	"Read the GIF blocks. Modified to return a form.  "
	| form extype block blocksize packedFields delay1 disposal frame |
	form := nil.
	frame := AnimatedImageFrame new.
	[ stream atEnd ] whileFalse: 
		[ block := self next.
		block 

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

[Mariano Martinez Peck]

On Wed, May 23, 2018 at 2:46 PM Sean P. DeNigris 
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.



>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

-- 
Mariano
http://marianopeck.wordpress.com

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

[Sean P. DeNigris]

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 :/



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Sean P. DeNigris]

Mariano Martinez Peck wrote
> From what I understand/remember/believe, the main reasons for
> building OSSubprocess were:

Thanks, Mariano!! Very informative :)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

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

[Mariano Martinez Peck]

Hi guys,

First, I would like to say that David was always very helpful, positive and
we have discussed and worked together a lot for this.

When I was sponsored to build OSSubprocess I already got the "we would like
this have this", so maybe some additional opinion from the ESUG board may
help clarify. From what I understand/remember/believe, the main reasons for
building OSSubprocess were:

1) *FFI-based tool*. Low the barrier of having to modify the VM to make a
fix. Despite all our efforts, we still have way more people able to deal
with FFI than with the VM. Even more if the VM is now shared under a common
project, in which is not always easy to plug Pharo-specific stuff.

2) *Cleaner/nicer API*. You may or may not agree with this and that's
perfect (we all have different opinions). When I was using OSProcess I
always thought the API was not as I would like to, so my goal was to
provide a API closer to my wishes. Again, not necessary better.

3) *Smaller functionality than OSProcess*: OSProcess is huge...it allows
you to fork squeak images, fork() + exec*()  whatever you want, runs on
Windows, etc. We wanted something smaller...just enough to be able to fork
processes. That is... to capture the most common/easy process forking.. But
if you really need something very advance, you may still go to bare metals
and use OSProcess approach (fork + exec).

4) *Added infrastructure*. We wanted the project to be on Git, with a very
detailed documentation, very high test coverage, and CI integration.


-

So...that is about the reasons... as to why it breaks when OSProcess is
loaded to, it's because for OSSubprocess I took the wonderful idea from
OSProcess of the child reaper. This is a process that runs on the Smalltalk
side and handles exception (via semaphore) when the child has died.   This
is (currently) only possible thanks to OSProcess primitive. That means
OSSubprocess still needs (one or very little) OSProcess primitives down in
the VM. When you load either of the projects, they launch the child reaper
process, register the semaphore etc etc. So the problem is when you loaded
one and you then try to load the second one, the initialization of the
second one you plug its own semaphore etc etc and so the previous gets
broken as it doesn't have a working child reaper process.

If someone has a better idea on how to solve this, then please speak up.


Cheers,


On Wed, May 23, 2018 at 11:12 AM Sean P. DeNigris 
wrote:

> Guillermo Polito wrote
> > I try not to depend on projects using OSProcess in that case.
>
> That is not exactly a robust solution! What is the only project providing
> the functionality you need depends on OSP?!
>
>
> Guillermo Polito wrote
> > I understand that the incompatibilities bother, but putting all the fault
> > in OSSubprocess and not in OSProcess seems not fair :)
>
> Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some
> of its functionality just recently, so I'd say it's fair indeed!
>
>
> Guillermo Polito wrote
> > Maybe both should be modified to be compatible?
>
> Maybe. I don't really understand the source of the incompatibility well
> enough.
>
>
> Guillermo Polito wrote
> > I found OSProcess API particularly bad. It's never clear to me whether to
> > use OSProcess, PipeableSomething or CommandWhatever (I don't even
> remember
> > the names of the things that **do work** and I have to look them every
> > time).
>
> The things you're describing are not accidental complexity, but the fact
> that OSP (and its companion CommandShell) actually have a far wider feature
> set than just simple commands. CommandShell makes many shell-like things
> possible in-image, but one doesn't have to use or even know anything about
> all that to do simple things. That said, every time I did into CS and see
> all the things that are possible I am amazed.
>
>
> Guillermo Polito wrote
> > Most people only want to do
> > output := OSProcess executeCommand: 'ls'.
> > Blocking. Recovering stdout. And that's all.
>
> (PipeableOSProcess command: 'ls') output
>
> That doesn't seem horribly complex to do in OSP ;)
>
>
> Guillermo Polito wrote
> > Well from a technical point of view, if you want to choose from one or
> > another today I'd say…
>
> Ah, interesting and informative. Thank you.
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-users] [Ann] Some new iceberg videos

[Tim Mackinnon]

Guille - the text reads very well, I’ll try and look at the videos later. I 
just submitted a PR to pharo to try and get the contributions text pointing to 
the “newer way” so that people don’t get off track (like we did earlier this 
week).

(Aside: Its quite nice having these docs in GitHub as does make it easier to 
propose fixes that people can review and accept/comment on).

Presumably those how to contribute docs should then also link to the below, so 
you also realise how you can help with Iceberg as well? And possibly those 
videos might also be helpful on the more generic - how to contribute to pharo 
(in general).

By the way - this video - 
https://www.youtube.com/watch?v=c0IgIT2s6Js&feature=youtu.be 
 has a very low 
quality compare to the others. I think maybe a setting was wrong when it was 
uploaded?

Tim

> On 23 May 2018, at 17:09, Guillermo Polito  wrote:
> 
> Hi all,
> 
> This time (just before releasing a new version of iceberg) I wanted to share 
> some videos with you.
> Feedback is welcome.
> 
> !! How to contribute to Iceberg
> https://youtu.be/yGr5HvVWM0M 
> 
> This video shows how to contribute to iceberg.
> For this, you should update your iceberg installation and then just do a pull 
> request.
> This means that you need to start by forking 
> https://github.com/pharo-vcs/iceberg 
> 
> - Path 1: Clone and pull (easy)
>   - Clone your fork
>   - Checkout the latest development branch (e.g., dev-0.7)
>   - Pull from pharo-vcs/iceberg
>   
>   This path does not always work, as this is kind of self-brain surgery. 
> Iceberg is updating itself.
>   If this does not work, go to path 2
>   
> - Path 2: Install from scratch (if Path 1 does not work)
>   - Use the script in the README file to unload and reinstall iceberg
>   - Make sure you use the latest development branch in the Metacello script 
> (e.g., dev-0.7)
>   - Clone your fork and checkout the development branch
>   
> Once you have the correct version, you can load the tests by loading the 
> development group of the baseline.
>   
> 
> !! Basic Branching and Merging
> https://youtu.be/c0IgIT2s6Js 
> 
> This video shows in a simple example how to branch, merge and checkout 
> different commits.
> In this video we first create a new class with a method, then we create 
> another branch and force a conflict. We resolve the conflict during merge.
> 
> In the middle, bonus feature, we checked out a commit and stayed in Detached 
> HEAD for a while ;)
> 
> !! Loading a baseline from your repository
> https://youtu.be/brUHEOr-p_E 
> 
> This video shows how to load a baseline from Iceberg's UI.
> We clone an existing project, see it is "Not loaded" and use Metacello plugin 
> to load the default group.
> 
> Enjoy,
> Guille
> 
> PS: Tomorrow I'll answer the threads about Iceberg that were going around 
> here in the mailing list. I was running today.

[Pharo-users] [Ann] Some new iceberg videos

[Guillermo Polito]

Hi all,

This time (just before releasing a new version of iceberg) I wanted to
share some videos with you.
Feedback is welcome.

!! How to contribute to Iceberg
https://youtu.be/yGr5HvVWM0M

This video shows how to contribute to iceberg.
For this, you should update your iceberg installation and then just do a
pull request.
This means that you need to start by forking
https://github.com/pharo-vcs/iceberg

- Path 1: Clone and pull (easy)
  - Clone your fork
  - Checkout the latest development branch (e.g., dev-0.7)
  - Pull from pharo-vcs/iceberg

  This path does not always work, as this is kind of self-brain surgery.
Iceberg is updating itself.
  If this does not work, go to path 2

- Path 2: Install from scratch (if Path 1 does not work)
  - Use the script in the README file to unload and reinstall iceberg
  - Make sure you use the latest development branch in the Metacello script
(e.g., dev-0.7)
  - Clone your fork and checkout the development branch

Once you have the correct version, you can load the tests by loading the
development group of the baseline.


!! Basic Branching and Merging
https://youtu.be/c0IgIT2s6Js

This video shows in a simple example how to branch, merge and checkout
different commits.
In this video we first create a new class with a method, then we create
another branch and force a conflict. We resolve the conflict during merge.

In the middle, bonus feature, we checked out a commit and stayed in
Detached HEAD for a while ;)

!! Loading a baseline from your repository
https://youtu.be/brUHEOr-p_E

This video shows how to load a baseline from Iceberg's UI.
We clone an existing project, see it is "Not loaded" and use Metacello
plugin to load the default group.

Enjoy,
Guille

PS: Tomorrow I'll answer the threads about Iceberg that were going around
here in the mailing list. I was running today.

Re: [Pharo-users] On UDP broadcast

[N. Bouraqadi]

Note that the package includes tests that show that the broadcast working :-)

Thanx Cédrick for the CC.
Noury
> On 21 May 2018, at 21:17, Cédrick Béler  wrote:
> 
> Noury did. He sent that on the other thread :
> 
> « Just want to point that I did some work late 2017 on UDP sockets including 
> multicast and broadcast. 
> The package named 'NetworkExtras' is part of the ReusableBricks repo of my 
> team.
> http://smalltalkhub.com/#!/~CAR/ReusableBricks 
> 
> It has some dependencies on other packages. »
> 
> It may help. I cc Noury. 
> 
> Cheers,
> 
> Cédrick 
> 
> Le 21 mai 2018 à 20:00, Sven Van Caekenberghe  > a écrit :
> 
>> 
>> 
>>> On 21 May 2018, at 19:37, Stephan Eggermont >> > wrote:
>>> 
>>> Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:.
 
 I can't get the broadcast sending via nc to work (like your terminal
 example). The -b nc option on macOS is not related to broadcasting.
>>> 
>>> Who’s allowed to broadcast? 
>> 
>> Yes, I vaguely remember that Unix permissions are involved, I just don't 
>> know how this works exactly.
>> 
>>> Stephan
>>> 
>>> 
>> 
>> 

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

Hi Henry,


[...] it might be possible to try to do this with FFI only?


If I understand you correctly, I could use FFI to call an external lib to  
perform the actual computation according to the rounding mode, right? In  
this case I'd be worry about the performance impact of many FFI calls.



For the same reason, I hope you intend roundByMethodXWhile: to be a
mandatory API, forgetting to set the mode back when done (or, never  
getting

there due to errors, etc) is an area best left unexplored ;)


I used roundByMethodXWhile: aBlock just to convey the idea that an API  
could work "local" and ensures resetting the rounding mode afterwards. =)


Best, Steffen

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

I'll cross-post there later. Thanks for the suggestion!

The application I have in mind is approximation algorithms for systems of  
linear equations or linear programs. Approximation algorithms, such as the  
power method, typically run until convergence of the solution vector is  
reached. However, determining convergence is usually done by computing the  
difference (epsilon) between the last two solutions and comparing it to  
some threshold. This may work in some cases but not in general, as the  
intermediate epsilon does not tell the distance to the actual solution.  
Interval iteration tackles this problem by approaching the solution from  
above and below. The difference between the upper and lower solution  
bounds determines the quality of the solution. However, if we use  
imprecise arithmetic (floats, doubles) it is important to round down/up in  
computing the lower/upper bounds.


Best, Steffen



Am .05.2018, 12:50 Uhr, schrieb Serge Stinckwich  
:



On Wed, May 23, 2018 at 11:47 AM Steffen Märcker  wrote:


*bump*

I guess there no way to do this now. But maybe a VM guy can give me how
difficult it might be to extend the VM accordingly.



​Yes you should followup this question to the VM mailing-list.
Can you open an issue here:  
https://github.com/PolyMathOrg/PolyMath/issues

so we don't forget about it ?​

​Do you have specific needs behind this ?​

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

[Sean P. DeNigris]

Guillermo Polito wrote
> I try not to depend on projects using OSProcess in that case.

That is not exactly a robust solution! What is the only project providing
the functionality you need depends on OSP?!


Guillermo Polito wrote
> I understand that the incompatibilities bother, but putting all the fault
> in OSSubprocess and not in OSProcess seems not fair :)

Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some
of its functionality just recently, so I'd say it's fair indeed!


Guillermo Polito wrote
> Maybe both should be modified to be compatible?

Maybe. I don't really understand the source of the incompatibility well
enough.


Guillermo Polito wrote
> I found OSProcess API particularly bad. It's never clear to me whether to
> use OSProcess, PipeableSomething or CommandWhatever (I don't even remember
> the names of the things that **do work** and I have to look them every
> time).

The things you're describing are not accidental complexity, but the fact
that OSP (and its companion CommandShell) actually have a far wider feature
set than just simple commands. CommandShell makes many shell-like things
possible in-image, but one doesn't have to use or even know anything about
all that to do simple things. That said, every time I did into CS and see
all the things that are possible I am amazed.


Guillermo Polito wrote
> Most people only want to do
> output := OSProcess executeCommand: 'ls'.
> Blocking. Recovering stdout. And that's all.

(PipeableOSProcess command: 'ls') output

That doesn't seem horribly complex to do in OSP ;)


Guillermo Polito wrote
> Well from a technical point of view, if you want to choose from one or
> another today I'd say…

Ah, interesting and informative. Thank you.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Henrik Sperre Johansen]

fesetround()/fegetround() are part of C99, and amazingly, also present in the
Windows CRT, it might be possible to try to do this with FFI only? 

IIRC the numerical model is supposed to act identical across platforms;
whether it would actually affect anything depends on how the VM achieves
that; I assume it's done by explicitly setting fp state to be identical
(including rounding mode), rather than using some library which avoids
x87/sse ops entirely, but I haven't actually looked.

For the same reason, I hope you intend roundByMethodXWhile: to be a
mandatory API, forgetting to set the mode back when done (or, never getting
there due to errors, etc) is an area best left unexplored ;)

Cheers,
Henry




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Thierry Goubier]

2018-05-23 15:28 GMT+02:00 Peter Uhnák :
>
>
> On Wed, May 23, 2018 at 6:42 AM, Ben Coman  wrote:
>>
>>
>>
>> On 22 May 2018 at 23:23, Tim Mackinnon  wrote:
>>>
>>> Hi - when trying out the new Iceberg with a bunch of developers and
>>> explaining the challenges of integrating git and files into a smalltalk
>>> realm of the image - there was a lot of interest in how this works.
>>>
>>> When you clone - you obviously see a series of files (in Tonel - nice)
>>> that are then brought into your image. If you edit a file like Readme.md
>>> (using a markdown editor) you will notice that git status will show you that
>>> this file has changed. However if you then edit some methods - and then look
>>> in the file system - git status doesn’t show these? This in retrospect
>>> possibly feels weird - or does it? I’m not sure anymore - and was wondering
>>> if there was a specific reason behind not mirroring code changes back to the
>>> file system as they happen?
>>
>>
>> I guess the conceptual model they have might be of Pharo as a text editor
>> directly changing the files.
>> Its interesting to consider how that would operate.  Changes are
>> immediately reflected in Epcia files,
>> and used to be immediately written to ".changes" file, so it seems
>> possible.
>
>
> This is indeed valuable when things go wrong.

At a point, I was considering using git as the changes file (every
method save and compile in Pharo -> a commit in git)

Didn't try to see if git would handle the load.

>> More interesting is what to do if the text file is edited outside Pharo.
>> If Pharo could observe this and then recompile the new file,
>> we might suddenly have a workable "external editor" workflow,
>> lack of which is a common complaint by some.
>
>
> I don't believe that it should be Pharo's concern to waste effort on
> supporting external editors -- it is throwing so much value of Pharo.
>
> That being said, until git conflicts can be resolved inside Pharo, it is
> necessary to be able to edit the files by hand. The ability to run the
> hand-resolved code without committing it (to verify it still works/compiles)
> seems like a worthwhile feature.

Good point.

>> However if you then edit some methods - and then look in the file system -
>> git status doesn’t show these? This in retrospect possibly feels weird - or
>> does it?
>
>
> With Iceberg you have two separate working copies. It is not weird from git
> perspective, however it is a rather unique setup -- even seasoned git users
> might say... "You can do that? :-o" :) (And yes, it adds some extra cost,
> but nothing is perfect.)

I considered eliminating one of the working copy when in Pharo, by
cloning repositories in RAW mode (without working tree). What you
wrote (the git fast-import layer) allows you to do that. But, to be
able to pull, you need to be able to be able to do a merge (and
resolve conflicts)... in Pharo memory.

Thierry

> Peter

Re: [Pharo-users] Why doesn't Pharo 7 Iceberg write changes to the git filesystem as you go?

[Peter Uhnák]

On Wed, May 23, 2018 at 6:42 AM, Ben Coman  wrote:

>
>
> On 22 May 2018 at 23:23, Tim Mackinnon  wrote:
>
>> Hi - when trying out the new Iceberg with a bunch of developers and
>> explaining the challenges of integrating git and files into a smalltalk
>> realm of the image - there was a lot of interest in how this works.
>>
>> When you clone - you obviously see a series of files (in Tonel - nice)
>> that are then brought into your image. If you edit a file like Readme.md
>> (using a markdown editor) you will notice that git status will show you
>> that this file has changed. However if you then edit some methods - and
>> then look in the file system - git status doesn’t show these? This in
>> retrospect possibly feels weird - or does it? I’m not sure anymore - and
>> was wondering if there was a specific reason behind not mirroring code
>> changes back to the file system as they happen?
>>
>
> I guess the conceptual model they have might be of Pharo as a text editor
> directly changing the files.
> Its interesting to consider how that would operate.  Changes are
> immediately reflected in Epcia files,
> and used to be immediately written to ".changes" file, so it seems
> possible.
>

This is indeed valuable when things go wrong.



> More interesting is what to do if the text file is edited outside Pharo.
> If Pharo could observe this and then recompile the new file,
> we might suddenly have a workable "external editor" workflow,
> lack of which is a common complaint by some.
>

I don't believe that it should be Pharo's concern to waste effort on
supporting external editors -- it is throwing so much value of Pharo.

That being said, until git conflicts can be resolved inside Pharo, it is
necessary to be able to edit the files by hand. The ability to run the
hand-resolved code without committing it (to verify it still
works/compiles) seems like a worthwhile feature.

However if you then edit some methods - and then look in the file system -
> git status doesn’t show these? This in retrospect possibly feels weird - or
> does it?
>

With Iceberg you have two separate working copies. It is not weird from git
perspective, however it is a rather unique setup -- even seasoned git users
might say... "You can do that? :-o" :) (And yes, it adds some extra cost,
but nothing is perfect.)

Peter

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Serge Stinckwich]

On Wed, May 23, 2018 at 11:47 AM Steffen Märcker  wrote:

> *bump*
>
> I guess there no way to do this now. But maybe a VM guy can give me how
> difficult it might be to extend the VM accordingly.
>
>
​Yes you should followup this question to the VM mailing-list.
Can you open an issue here: https://github.com/PolyMathOrg/PolyMath/issues
so we don't forget about it ?​

​Do you have specific needs behind this ?​

-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

*bump*

I guess there no way to do this now. But maybe a VM guy can give me how  
difficult it might be to extend the VM accordingly.


Best, Steffen

Am .01.2018, 12:27 Uhr, schrieb Steffen Märcker :


Hi,

is there any way to set the rounding mode for IEEE floating point
operations? Maybe something like

Double roundToMinusInfWhile: [... code goes here ...]Double  
roundToZeroWhile: [... more code here ...]


If not, is it possible to add this behavior, e.g., via a custom  
primitive?


Best, Steffen