date:20170606

Hi Oleks,

This is probably out of scope (check with your mentors), but I was curious
how text processing and inter-table lookups might fit into you project?

Check out the Excel side-story at [1] (starting just above the picture of
the red tree) "Everybody thought of Excel as a financial modeling
application [...] for creating calculation models with formulas and stuff.
... [but] most people just used Excel to make lists". This is exactly my
personal experience.

The greatest practical value I've had from Excel is massaging text lists.
Some use cases:

A. getting a bunch of messy hand typed data that needs cleaning up to be
consistent before deriving statistics from it. There is no sense
programming the whole workflow since its a highly iterative process to work
through issues as you discover them. Issues are on-shot, but you want to
apply it to 1000 rows.

B. tracking the status of 1000s of drawings as they progress through a
workflow. Tagging who is working on each drawing, status and using
AutoFilter to print out "Drawings To Go" lists.

C. managing a photo shoot for a school ball, recording orders and
generating filenames to copy originals to a USB stick to take to the photo
lab, such that duplicate orders each have a single file with the filename
printed on the back making it easier to sort into envelopes for each order.
(This is from last week so I can provide a sample Excel file for it)

For a detailed example, sometimes I might need to compare the basenames of
the files in two folders:

1. In both folders A & B, from the command line I'd do `ls -l > ls.txt`

2. I'd load both text files into Excel, one per tab, where each line
appeared in a single column.

3. I split on spaces to convert single column into multiple columns [2]

4. I'd split off the filename extension. So I'd need to reverse the string
to determine the location of the last period and store that in a temporary
column. Then two more columns hold the formulas extracting the first and
second parts of the split using LEFT() and RIGHT().

5. Then in next column I'd have a formula using VLOOKUP() [4] to see if a
row's basename appears in any row of the other tab.

6. I'd then do conditional formatting highlighting the row green if the
VLOOKUP() was found.

"Text Data Grooming" would be a popular horizonal application demonstrating
Pharo's liveness (indeed Excel can be considered a "live" environment.,
saving its "image" to a xls file). I'd very much love to use Pharo for
this instead of Excel.

cheers -ben

[1] https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/
[2]
https://support.office.com/en-us/article/Split-text-into-different-columns-with-the-Convert-Text-to-Columns-Wizard-30b14928-5550-41f5-97ca-7a3e9c363ed7
[3]
https://superuser.com/questions/121618/any-excel-function-that-will-reverse-a-string
[4]
https://support.office.com/en-us/article/VLOOKUP-function-0bbc8083-26fe-4963-8ab8-93a18ad188a1

Re: [Pharo-users] [ANN] Pharo 6.0 released!

2017-06-06 Thread peter yoo

Congratulations! and thanks to Pharo DEV team!

Re: [Pharo-users] How to deploy headless app without changes and source files?

2017-06-06 Thread Andreas Sunardi

For now, in my 'deployed' image, I have:
1. Disabled SourceFilesArray >> forceChangesToDisk
I did not find any code branch that would avoid this, so for now I just
made it do nothing. Maybe I should disable ChangesLog >> logChange: instead.

2. Disabled PharoFilesOpener >> changesFileOrNil
Same story. But this only causes warning get printed out, not error.
Disabling it removes the warning message.

3. Set changesFileStream to nil (SourceFiles changesFileStream: nil).
Some code does have guard against nil value for this changes stream.

This works for me if I do not have the changes file with the image. If I
have the changes file and it's read-only, that's a different problem.

It seems that this was possible before, judging from the older links I
found in my original email and the existence of some guards against
non-existence changes file.

I'll check those links and perhaps see if I can be helpful there, but I
right now have delivery to make. And I can't wait to try Pharo 6 too.

--
Andreas


On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman  wrote:

>
>
> On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi 
> wrote:
>
>> Hi Stef,
>>
>> I can't have changes file bundled with the tool because the tool is
>> installed in a centralized location in my network and multiple users will
>> run it. So the image is in a central location and read-only and so is the
>> changes file (if I must have a changes file). The tool is only a processor.
>> It does not need to keep/save its state.
>>
>> Hence, I cannot have multiple users writing to that one and the same
>> changes file.
>>
>> I'm trying to dissect the call chain to ChangesLog and try to cut it so
>> Pharo won't write to the changes file. I'm sure I should not do this. There
>> must be a better way.
>>
>
> I guess this use case just hasn't been critical for other people (there
> are lots of competing priorities) and they've found ways of working around
> it, like making your network located tool a script that copies itself
> itself to a use folder and run from there.  But of course it would be
> better for Pharo to work cleanly without a changes file. To make it better,
> someone has to do it, so feel free to propose some code changes (with
> discussion of such on pharo-dev list).
>
> Here is one hint (something related I worked on recently)...
> https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-
> when-sources-file-missing
> To view the changes, open image 60494 (easiest using PharoLauncher)
> and load the slice.
>
> Filtering the issue tracker on "changes file" pops up a few other
> possibilities (I haven't reviewed them, and you might find others)
> https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-
> file-is-not-writable
> https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-
> that-opens-the-sources-and-changes-files
>
> cheers -ben
>
>
>>
>> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> We started to work on making the system ready to stop using these files.
>>> There are two things.
>>> - the changes are a tape that logs what you are doing and right now
>>> the system is not done to accept not to log
>>> So I imagine that you can remove the changes file but then do not
>>> compile code.
>>> - I do not get the "so I can't have changes file bundled with the tool."
>>> you do not have a bat or script that launches the application that is
>>> somewhere in a folder where you have the vm and the image? you could
>>> have the changes file there.
>>>
>>> We are interested in your scenario because last year I got a guy
>>> working on making pharo silent. I do not know if its changes got
>>> integrated into pharo.
>>> This is really something that we want to have.
>>> - having sources and changes in a specific location
>>> - having no source and no changes (even if it means lose your code).
>>> - ...
>>>
>>> Stef
>>>
>>> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi 
>>> wrote:
>>> > Sorry to bring this up again. But it turns out that I had the image
>>> > directory writable by myself, so it created a new changes file. That's
>>> why
>>> > Pharo didn't complain about missing changes file. When I removed write
>>> > permission in the tool installation, Pharo gives error for not having
>>> or not
>>> > able to write to changes file.
>>> >
>>> > I guess I'm back to the problem how to deploy a tool without changes
>>> file. I
>>> > have multiple users that will be running this tool, which is installed
>>> in a
>>> > centralized site, so I can't have changes file bundled with the tool.
>>> >
>>> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi 
>>> wrote:
>>> >>
>>> >> I had my changes and sources files in the bundle but has their write
>>> >> permission removed, and that causes the error. Simply deploying the
>>> tool
>>> >> without the changes file seems to fix it. Pharo5 doesn't complain if
>>> the
>>> >> changes file

Re: [Pharo-users] How to deploy headless app without changes and source files?

On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi  wrote:

> Hi Stef,
>
> I can't have changes file bundled with the tool because the tool is
> installed in a centralized location in my network and multiple users will
> run it. So the image is in a central location and read-only and so is the
> changes file (if I must have a changes file). The tool is only a processor.
> It does not need to keep/save its state.
>
> Hence, I cannot have multiple users writing to that one and the same
> changes file.
>
> I'm trying to dissect the call chain to ChangesLog and try to cut it so
> Pharo won't write to the changes file. I'm sure I should not do this. There
> must be a better way.
>

I guess this use case just hasn't been critical for other people (there are
lots of competing priorities) and they've found ways of working around it,
like making your network located tool a script that copies itself itself to
a use folder and run from there.  But of course it would be better for
Pharo to work cleanly without a changes file. To make it better, someone
has to do it, so feel free to propose some code changes (with discussion of
such on pharo-dev list).

Here is one hint (something related I worked on recently)...
https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file-missing
To view the changes, open image 60494 (easiest using PharoLauncher)
and load the slice.

Filtering the issue tracker on "changes file" pops up a few other
possibilities (I haven't reviewed them, and you might find others)
https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writable
https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-sources-and-changes-files

cheers -ben


>
> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse  > wrote:
>
>> We started to work on making the system ready to stop using these files.
>> There are two things.
>> - the changes are a tape that logs what you are doing and right now
>> the system is not done to accept not to log
>> So I imagine that you can remove the changes file but then do not compile
>> code.
>> - I do not get the "so I can't have changes file bundled with the tool."
>> you do not have a bat or script that launches the application that is
>> somewhere in a folder where you have the vm and the image? you could
>> have the changes file there.
>>
>> We are interested in your scenario because last year I got a guy
>> working on making pharo silent. I do not know if its changes got
>> integrated into pharo.
>> This is really something that we want to have.
>> - having sources and changes in a specific location
>> - having no source and no changes (even if it means lose your code).
>> - ...
>>
>> Stef
>>
>> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi 
>> wrote:
>> > Sorry to bring this up again. But it turns out that I had the image
>> > directory writable by myself, so it created a new changes file. That's
>> why
>> > Pharo didn't complain about missing changes file. When I removed write
>> > permission in the tool installation, Pharo gives error for not having
>> or not
>> > able to write to changes file.
>> >
>> > I guess I'm back to the problem how to deploy a tool without changes
>> file. I
>> > have multiple users that will be running this tool, which is installed
>> in a
>> > centralized site, so I can't have changes file bundled with the tool.
>> >
>> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi 
>> wrote:
>> >>
>> >> I had my changes and sources files in the bundle but has their write
>> >> permission removed, and that causes the error. Simply deploying the
>> tool
>> >> without the changes file seems to fix it. Pharo5 doesn't complain if
>> the
>> >> changes file isn't there.
>> >>
>> >> However, without the sources file, I get this warning that pharo cannot
>> >> locate the sources file. Including the sources file in the deployed
>> tool is
>> >> fine with me.
>> >>
>> >> So, I think that's my solution. Thanks!
>> >>
>> >>
>> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi 
>> >> wrote:
>> >>>
>> >>> I found this StackOverflow question:
>> >>>
>> >>> https://stackoverflow.com/questions/14737695/is-it-possible-
>> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328
>> >>>
>> >>> and this older forum thread:
>> >>>
>> >>> https://www.mail-archive.com/pharo-project@lists.gforge.inri
>> a.fr/msg21170.html
>> >>>
>> >>> I'm using Pharo5.0 and neither of these options is available anymore.
>> >>> What is the new way to do this?
>> >>>
>> >>> --
>> >>> Andreas Sunardi
>> >>
>> >>
>> >
>>
>>
>

Re: [Pharo-users] How to use uFFI with String

Cool. Looks good.
cheers -ben

On Wed, Jun 7, 2017 at 2:20 AM, Stephane Ducasse 
wrote:

> Hi ben
>
> Yes I changed it :)
> Stef
>
> On Mon, May 29, 2017 at 10:16 AM, Ben Coman  wrote:
> > On Mon, May 29, 2017 at 7:24 AM, horrido 
> wrote:
> >> I don't use GitHub. I've never used GitHub. I don't know how to use
> GitHub.
> >>
> >> I looked at making a pull request and I was totally stymied. "Clueless"
> >> doesn't even begin to describe how I felt.
> >
> > Everyone starts there.  Its a useful skill to have, so if you are
> > interested to learn, here's a quickstart guide...
> > (Note since its a text file, we are shortcutting so you don't even
> > need git on your local machine)
> > 1. Click on this link.
> > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/
> master/Morphic/Morphic.pier
> > 2. Click the  button in the top tight, then browse to
> > "Morphic.pier" in your fork.
> > 3. To the right of the  buttons, click the 
> > button to edit the file.
> > 4. After editing, at the bottom select "Create a new branch for this
> > commit and start a pull request"
> > and enter commit title, comment and new-branch-name to reflect your
> > contribution. Click 
> > 5. Now looking at "Open a pull request", this is issuing a PR to your
> > own fork.  We need to change to the upstream fork.  At the top click
> > on "forked from SquareBracketAssociates/UpdatedPharoByExample" .
> > 6. Under "Your recently pushed branches" click 
> > 7. Check...
> >   base fork: SquareBracketAssociates/UpdatedPharoByExample
> >   base: master
> >   head fork: YourName/UpdatedPharoByExample
> >   compare: your new-branch-name
> > Review the diff, enter PR title and comment, then click  request>.
> >
> > If you have problems, try to catch me on Discord...
> > https://discord.gg/dKv4qR/KCKQSSt
> >
> > cheers -ben
> >
> > P.S. @Stef, btw, it looks like "the guidelines for contributing" is
> > out of date...
> >https://github.com/SquareBracketAssociates/
> UpdatedPharoByExample/blob/master/CONTRIBUTING.md
> >"This is a test to see if it makes sense to convert PharoByExample
> > into pier format."
> >
> >
> >>
> >>
> >> Ben Coman wrote
> >>> On Sat, May 27, 2017 at 9:15 PM, horrido 
> >>
> >>> horrido.hobbies@
> >>
> >>>  wrote:
>  Yes, I did. I found it difficult to understand. It would be nice to
> have
>  some
>  clear examples in the documentation, for example, really simple and
>  common
>  situations such as a C function returning an integer in a
>  passed-by-reference argument.
> 
>  Speaking of documentation, in "Pharo by Example 50," I found this
>  statement:
> 
> > (Recall that you should set halosEnabled in the Preferences
>  browser.)
> 
>  However, nowhere else in the book is there any reference to
> halosEnabled
>  or
>  Preferences browser.
> >>>
> >>> Nice pick up.  Now in Settings (in a fresh 60473 image), filtering on
> >>> "halo" shows only:
> >>>  * Cycle both directions
> >>>  * Encloses fullbounds
> >>>  * Exhibits bounds
> >>> so the comment seems irrelevant
> >>>
> >>> and #halosEnabled & #halosEnabled: each have one implementor
> class-side of
> >>> Morph
> >>> with one sender from MorphTest each, and one sender from
> Morph>>addHalo:
> >>>
> >>> and "Morph halosEnabled" ==> true,  so the statement seems unnecessary.
> >>> Would you like to contribute a pull request removing it?
> >>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/
> master/Morphic/Morphic.pier
> >>>
> >>>
>  Did you guys forget and leave out a chunk of the book?
> >>>
> >>> Its an evolutionary book originally from Squeak.  It could well be
> >>> that some parts of the book have been cleaned
> >>> better than others to match Image changes.  Thanks for reporting, and
> >>> even better if you can correct it.
> >>>
> >>> cheers -ben
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context: http://forum.world.st/How-to-
> use-uFFI-with-String-tp4947890p4948512.html
> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> >>
> >
>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

2017-06-06 Thread Andreas Sunardi

Hi Stef,

I can't have changes file bundled with the tool because the tool is
installed in a centralized location in my network and multiple users will
run it. So the image is in a central location and read-only and so is the
changes file (if I must have a changes file). The tool is only a processor.
It does not need to keep/save its state.

Hence, I cannot have multiple users writing to that one and the same
changes file.

I'm trying to dissect the call chain to ChangesLog and try to cut it so
Pharo won't write to the changes file. I'm sure I should not do this. There
must be a better way.


On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse 
wrote:

> We started to work on making the system ready to stop using these files.
> There are two things.
> - the changes are a tape that logs what you are doing and right now
> the system is not done to accept not to log
> So I imagine that you can remove the changes file but then do not compile
> code.
> - I do not get the "so I can't have changes file bundled with the tool."
> you do not have a bat or script that launches the application that is
> somewhere in a folder where you have the vm and the image? you could
> have the changes file there.
>
> We are interested in your scenario because last year I got a guy
> working on making pharo silent. I do not know if its changes got
> integrated into pharo.
> This is really something that we want to have.
> - having sources and changes in a specific location
> - having no source and no changes (even if it means lose your code).
> - ...
>
> Stef
>
> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi 
> wrote:
> > Sorry to bring this up again. But it turns out that I had the image
> > directory writable by myself, so it created a new changes file. That's
> why
> > Pharo didn't complain about missing changes file. When I removed write
> > permission in the tool installation, Pharo gives error for not having or
> not
> > able to write to changes file.
> >
> > I guess I'm back to the problem how to deploy a tool without changes
> file. I
> > have multiple users that will be running this tool, which is installed
> in a
> > centralized site, so I can't have changes file bundled with the tool.
> >
> > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi 
> wrote:
> >>
> >> I had my changes and sources files in the bundle but has their write
> >> permission removed, and that causes the error. Simply deploying the tool
> >> without the changes file seems to fix it. Pharo5 doesn't complain if the
> >> changes file isn't there.
> >>
> >> However, without the sources file, I get this warning that pharo cannot
> >> locate the sources file. Including the sources file in the deployed
> tool is
> >> fine with me.
> >>
> >> So, I think that's my solution. Thanks!
> >>
> >>
> >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi 
> >> wrote:
> >>>
> >>> I found this StackOverflow question:
> >>>
> >>> https://stackoverflow.com/questions/14737695/is-it-
> possible-to-deploy-a-pharo-image-without-changes-and-
> sources-files/14747328
> >>>
> >>> and this older forum thread:
> >>>
> >>> https://www.mail-archive.com/pharo-project@lists.gforge.
> inria.fr/msg21170.html
> >>>
> >>> I'm using Pharo5.0 and neither of these options is available anymore.
> >>> What is the new way to do this?
> >>>
> >>> --
> >>> Andreas Sunardi
> >>
> >>
> >
>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

We started to work on making the system ready to stop using these files.
There are two things.
- the changes are a tape that logs what you are doing and right now
the system is not done to accept not to log
So I imagine that you can remove the changes file but then do not compile code.
- I do not get the "so I can't have changes file bundled with the tool."
you do not have a bat or script that launches the application that is
somewhere in a folder where you have the vm and the image? you could
have the changes file there.

We are interested in your scenario because last year I got a guy
working on making pharo silent. I do not know if its changes got
integrated into pharo.
This is really something that we want to have.
- having sources and changes in a specific location
- having no source and no changes (even if it means lose your code).
- ...

Stef

On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi  wrote:
> Sorry to bring this up again. But it turns out that I had the image
> directory writable by myself, so it created a new changes file. That's why
> Pharo didn't complain about missing changes file. When I removed write
> permission in the tool installation, Pharo gives error for not having or not
> able to write to changes file.
>
> I guess I'm back to the problem how to deploy a tool without changes file. I
> have multiple users that will be running this tool, which is installed in a
> centralized site, so I can't have changes file bundled with the tool.
>
> On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi  wrote:
>>
>> I had my changes and sources files in the bundle but has their write
>> permission removed, and that causes the error. Simply deploying the tool
>> without the changes file seems to fix it. Pharo5 doesn't complain if the
>> changes file isn't there.
>>
>> However, without the sources file, I get this warning that pharo cannot
>> locate the sources file. Including the sources file in the deployed tool is
>> fine with me.
>>
>> So, I think that's my solution. Thanks!
>>
>>
>> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi 
>> wrote:
>>>
>>> I found this StackOverflow question:
>>>
>>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pharo-image-without-changes-and-sources-files/14747328
>>>
>>> and this older forum thread:
>>>
>>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.html
>>>
>>> I'm using Pharo5.0 and neither of these options is available anymore.
>>> What is the new way to do this?
>>>
>>> --
>>> Andreas Sunardi
>>
>>
>

Re: [Pharo-users] [ANN] Pharo 6.0 released!

2017-06-06 Thread Stephan Eggermont


On 06/06/17 17:11, Esteban Lorenzano wrote:

Dear World,

The time has come for Pharo 6.0!


Yes! Well done!

Stephan

Re: [Pharo-users] is it related to Freetype or Athens?

Hilaire

If I remember correcly, there is a bug in cairo so igor was sometimes
forced to change the font size multiplying a little
to force the plugin to react.

Stef

On Tue, Jun 6, 2017 at 7:33 PM, Hilaire  wrote:
> Hi there,
>
> A Dr. Geo user on Ubuntu 64bits 16.04 got that buggy rendering of the
> canvas, then on some situation the rendering completely stop on a red
> screen, with a stack showing may be a zero divide error. I did not get
> access to the PharoDebog yet.
>
> Fonts on the screenshot is not right too. Could it be a mixed problem
> between FreeType and Cairo? Any first though on the issue welcome.
>
> Given the fact Dr. Geo is still based on Pharo3 and it works pretty fine
> on my old Ubuntu 12.07 derived system, it may be time to port the newer
> Pharo6.
>
> Congrats for the Pharo6 release.
>
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>

Re: [Pharo-users] How to use uFFI with String

Hi ben

Yes I changed it :)
Stef

On Mon, May 29, 2017 at 10:16 AM, Ben Coman  wrote:
> On Mon, May 29, 2017 at 7:24 AM, horrido  wrote:
>> I don't use GitHub. I've never used GitHub. I don't know how to use GitHub.
>>
>> I looked at making a pull request and I was totally stymied. "Clueless"
>> doesn't even begin to describe how I felt.
>
> Everyone starts there.  Its a useful skill to have, so if you are
> interested to learn, here's a quickstart guide...
> (Note since its a text file, we are shortcutting so you don't even
> need git on your local machine)
> 1. Click on this link.
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/master/Morphic/Morphic.pier
> 2. Click the  button in the top tight, then browse to
> "Morphic.pier" in your fork.
> 3. To the right of the  buttons, click the 
> button to edit the file.
> 4. After editing, at the bottom select "Create a new branch for this
> commit and start a pull request"
> and enter commit title, comment and new-branch-name to reflect your
> contribution. Click 
> 5. Now looking at "Open a pull request", this is issuing a PR to your
> own fork.  We need to change to the upstream fork.  At the top click
> on "forked from SquareBracketAssociates/UpdatedPharoByExample" .
> 6. Under "Your recently pushed branches" click 
> 7. Check...
>   base fork: SquareBracketAssociates/UpdatedPharoByExample
>   base: master
>   head fork: YourName/UpdatedPharoByExample
>   compare: your new-branch-name
> Review the diff, enter PR title and comment, then click .
>
> If you have problems, try to catch me on Discord...
> https://discord.gg/dKv4qR/KCKQSSt
>
> cheers -ben
>
> P.S. @Stef, btw, it looks like "the guidelines for contributing" is
> out of date...
>
> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/master/CONTRIBUTING.md
>"This is a test to see if it makes sense to convert PharoByExample
> into pier format."
>
>
>>
>>
>> Ben Coman wrote
>>> On Sat, May 27, 2017 at 9:15 PM, horrido 
>>
>>> horrido.hobbies@
>>
>>>  wrote:
 Yes, I did. I found it difficult to understand. It would be nice to have
 some
 clear examples in the documentation, for example, really simple and
 common
 situations such as a C function returning an integer in a
 passed-by-reference argument.

 Speaking of documentation, in "Pharo by Example 50," I found this
 statement:

> (Recall that you should set halosEnabled in the Preferences
 browser.)

 However, nowhere else in the book is there any reference to halosEnabled
 or
 Preferences browser.
>>>
>>> Nice pick up.  Now in Settings (in a fresh 60473 image), filtering on
>>> "halo" shows only:
>>>  * Cycle both directions
>>>  * Encloses fullbounds
>>>  * Exhibits bounds
>>> so the comment seems irrelevant
>>>
>>> and #halosEnabled & #halosEnabled: each have one implementor class-side of
>>> Morph
>>> with one sender from MorphTest each, and one sender from Morph>>addHalo:
>>>
>>> and "Morph halosEnabled" ==> true,  so the statement seems unnecessary.
>>> Would you like to contribute a pull request removing it?
>>> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/blob/master/Morphic/Morphic.pier
>>>
>>>
 Did you guys forget and leave out a chunk of the book?
>>>
>>> Its an evolutionary book originally from Squeak.  It could well be
>>> that some parts of the book have been cleaned
>>> better than others to match Image changes.  Thanks for reporting, and
>>> even better if you can correct it.
>>>
>>> cheers -ben
>>
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://forum.world.st/How-to-use-uFFI-with-String-tp4947890p4948512.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>
>

Re: [Pharo-users] How to deploy headless app without changes and source files?

2017-06-06 Thread Andreas Sunardi

Sorry to bring this up again. But it turns out that I had the image
directory writable by myself, so it created a new changes file. That's why
Pharo didn't complain about missing changes file. When I removed write
permission in the tool installation, Pharo gives error for not having or
not able to write to changes file.

I guess I'm back to the problem how to deploy a tool without changes file.
I have multiple users that will be running this tool, which is installed in
a centralized site, so I can't have changes file bundled with the tool.

On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi  wrote:

> I had my changes and sources files in the bundle but has their write
> permission removed, and that causes the error. Simply deploying the tool
> without the changes file seems to fix it. Pharo5 doesn't complain if the
> changes file isn't there.
>
> However, without the sources file, I get this warning that pharo cannot
> locate the sources file. Including the sources file in the deployed tool is
> fine with me.
>
> So, I think that's my solution. Thanks!
>
>
> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi 
> wrote:
>
>> I found this StackOverflow question:
>> https://stackoverflow.com/questions/14737695/is-it-possible-
>> to-deploy-a-pharo-image-without-changes-and-sources-files/14747328
>>
>> and this older forum thread:
>> https://www.mail-archive.com/pharo-project@lists.gforge.inri
>> a.fr/msg21170.html
>>
>> I'm using Pharo5.0 and neither of these options is available anymore.
>> What is the new way to do this?
>>
>> --
>> Andreas Sunardi
>>
>
>

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.0 released!

Tx torsten.
New space is opening to us :)

On Tue, Jun 6, 2017 at 7:49 PM, Torsten Bergmann  wrote:
> Dear friends,
>
> Yes - really an impressive release. With many cleanups and new treasures in 
> the image - but also many
> shiny new/updated external packages and projects (like Roassal, Polymath, 
> Calypso browser, ... to name just a few).
>
> Thanks to all who helped - especially to the ones who cared and also worked 
> on the not so interesting but
> often hard to solve issues or boring but necessary parts or infrastructure.
>
> The new git integration in Pharo and the included Iceberg tool will allow us 
> to work with services
> like GitHub, GitLab, BitBucket - even own local git servers (for instance 
> setups using Gogs.io). We can now manage
> project resources beside code, commit several packages at once and branch and 
> merge as necessary.
> This really rocks!
>
> Many thanks also to all the contributors of the OpenSmalltalk initiative - it 
> is also impressive
> how much progress was done on VM side. Also thanks to the ones writing new 
> books, articles and tutorials
> so other can learn and enjoy such a fantastic dynamic and lively system.
>
> We still have a way to go for Pharo 7 and onwards. I'm eager to play with the 
> new git based development process and
> interested on how we can manage to build our future Pharo based on the 
> bootstrap efforts.
>
> Even when not finally there ... step by step it goes!
>
> Bye
> T.
>
>
>
> Gesendet: Dienstag, 06. Juni 2017 um 17:11 Uhr
> Von: "Esteban Lorenzano" 
> An: "Any question about pharo is welcome" , 
> "Pharo Development List" , 
> members-consort...@pharo.org, "Seaside - general discussion" 
> , "list ESUG Mailing" 
> 
> Betreff: [Pharo-dev] [ANN] Pharo 6.0 released!
>
> Dear World,
>
> The time has come for Pharo 6.0!
>
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
>
> This is our most significant release yet. Here are some highlights:
>
>
> - Pharo is now provided in 64-bit version in Linux and OSX and brings even 
> better performance and stability (beware, 64bits version is a new technology 
> and a small amount of tests is still failing)
> - A new code changes management system named Epicea for easier reviewing and 
> recovering of your code easily
> - Integrated support for Git through an easy-to-use tool for repositories and 
> commits management named Iceberg (as a preview for Pharo 6, it will be the 
> default in Pharo 7)
> - The unified foreign function interface (UnifiedFFI) for interfacing with 
> the outside world is significantly improved
> - The PharoVM is now part of OpenSmalltalk initiative
> - Introduction of object immutability, alternative bytecode sets and block 
> closures independent of outer context
> - Pharo can now be bootstrapped from source code managed by Git
> - Pharo modularity is improved
> - Pharo is faster
> - The Dark Theme was improved and set as default color theme of Pharo
>
>
>
> These are just the more prominent highlights, but the details are just as 
> important. We have closed 1474 issues in Pharo 6.0 (a more complete changelog 
> can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md).
>
> While the technical improvements are significant (starting the transition to 
> 64bits is a remarkable achievement), still the most impressive fact is that 
> the new code that got in the main Pharo 6.0 image was contributed by more 
> than 80 people.
>
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors of this release:
>
> Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, 
> Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, 
> Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale 
> Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk 
> Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan Donahue, 
> Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo Polito, Gustavo 
> Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, Holger Hans, Jan 
> Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. Subramaniam, Ken 
> Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas Godoy, Marcus Denker, 
> Mariano Martinez Peck, Marion Noirbent, Martin Dias, Max Leske, Maxime 
> Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel Campusano, Milton Mamani, 
> Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, Nicolas Passerini, Norbert 
> Hartl, Offray Luna, Pablo Tesone, Paul De Bruicker, Pavel Krivanek, Peter 
> Uhnak, Philippe Back, Roger Stebler, Ronie Salgado, Sean DeNigris, Serge 
> Stinckwich, Skip Lentz, Sophie Kaleba, Stefan Reichhart, Stephan

Re: [Pharo-users] Wiring objects, IoC and Service Locator

2017-06-06 Thread Attila Magyar

I don't think using a DI container worth the effort. They add lots of
complexities and solve very little. For some reason DI containers became
very popular in the Java world, but if you take a look at other programming
communities you'll realize that many people are perfectly happy without
using these containers. Using DI and using a DI container is orthogonal. As
you also said you can just pass dependencies to objects to achieve loose
coupling. Yes, you have to do this manually but what's the big deal? We're
talking about code with cyclomatic complexity of 1. Calling a constructor is
not a problem that need to be solved. Using an external XML configuration to
describe object wiring is the worst idea ever.

Here is an article about using plain old object composition to do DI

http://blog.davidpeterson.co.uk/2011/01/object-oriented-example.html

Some more thoughts about the problems associated with DI containers:

http://www.natpryce.com/articles/000783.html
http://higherorderlogic.com/2011/07/is-dependency-injection-like-facebook



--
View this message in context: 
http://forum.world.st/Wiring-objects-IoC-and-Service-Locator-tp4949280p4949720.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.0 released!

2017-06-06 Thread Raffaello Giulietti


On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano  wrote:
Dear World,

The time has come for Pharo 6.0!



Nice!
Thanks to all contributors.

Greetings
Raffaello

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.0 released!

2017-06-06 Thread Sven Van Caekenberghe


> On 6 Jun 2017, at 18:18, Ben Coman  wrote:
> 
> 
> 
> On Tue, Jun 6, 2017 at 11:11 PM, Esteban Lorenzano  
> wrote:
> Dear World,
> 
> The time has come for Pharo 6.0!
> 
> Woot!
> cheers -ben

Super. Thank you all.

Re: [Pharo-users] [ANN] Pharo 6.0 released!

2017-06-06 Thread Norbert Hartl

It is really great! Thank you all! I'm glad the struggles with 32 bit libraries 
will have an end for normal deployments. The same goes for uFFI that makes 
things so much easier. And of course the rest of the list of changes is 
impressive as always.

Glad to be part of this community. You rock!

Norbert

> Am 06.06.2017 um 17:11 schrieb Esteban Lorenzano :
> 
> Dear World,
> 
> The time has come for Pharo 6.0!
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> This is our most significant release yet. Here are some highlights:
> 
> - Pharo is now provided in 64-bit version in Linux and OSX and brings even 
> better performance and stability (beware, 64bits version is a new technology 
> and a small amount of tests is still failing)
> - A new code changes management system named Epicea for easier reviewing and 
> recovering of your code easily
> - Integrated support for Git through an easy-to-use tool for repositories and 
> commits management named Iceberg (as a preview for Pharo 6, it will be the 
> default in Pharo 7)
> - The unified foreign function interface (UnifiedFFI) for interfacing with 
> the outside world is significantly improved
> - The PharoVM is now part of OpenSmalltalk initiative
> - Introduction of object immutability, alternative bytecode sets and block 
> closures independent of outer context
> - Pharo can now be bootstrapped from source code managed by Git
> - Pharo modularity is improved
> - Pharo is faster
> - The Dark Theme was improved and set as default color theme of Pharo
> 
> 
> 
> These are just the more prominent highlights, but the details are just as 
> important. We have closed 1474 issues in Pharo 6.0 (a more complete changelog 
> can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60ChangeLogs.md
>  
> ).
>  
> 
> While the technical improvements are significant (starting the transition to 
> 64bits is a remarkable achievement), still the most impressive fact is that 
> the new code that got in the main Pharo 6.0 image was contributed by more 
> than 80 people.
> 
> Pharo is more than code. It is an exciting project involving energetic 
> people. We thank all the contributors of this release:
> 
> Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, 
> Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, 
> Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale 
> Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk 
> Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan Donahue, 
> Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo Polito, Gustavo 
> Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, Holger Hans, Jan 
> Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. Subramaniam, Ken 
> Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas Godoy, Marcus Denker, 
> Mariano Martinez Peck, Marion Noirbent, Martin Dias, Max Leske, Maxime 
> Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel Campusano, Milton Mamani, 
> Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, Nicolas Passerini, Norbert 
> Hartl, Offray Luna, Pablo Tesone, Paul De Bruicker, Pavel Krivanek, Peter 
> Uhnak, Philippe Back, Roger Stebler, Ronie Salgado, Sean DeNigris, Serge 
> Stinckwich, Skip Lentz, Sophie Kaleba, Stefan Reichhart, Stephan Eggermont, 
> Stephane Ducasse, Sven Van Caekenberghe, Thibault Arloing, Thibault Arloing, 
> Thibault Raffaillac, Thierry Goubier, Thomas Heniart, Tommaso Dal Sasso, 
> Torsten Bergmann, Tudor Girba, Udo Schneider, Valentin Ryckewaert, Vincent 
> Blondeau, Werner Kassens, Yuriy Tymchuk
> 
> (If you contributed with Pharo 6.0 development in any way and we missed your 
> name, please send us a mail and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download 
> Learn Pharo: http://pharo.org/documentation

Re: [Pharo-users] Wiring objects, IoC and Service Locator

On Tue, Jun 6, 2017 at 9:11 PM, Vitor Medina Cruz 
wrote:

> Thanks for the detailed answer ben :)
>
> I will try to clarify a little: the question is how to loosely wire
> objects, such as MovieLister to MovieFinder, so that changes in the wiring
> can be made without effort. In Java, people use DI containers and xml files
> or annotations to provide the wiring configuration, which is easy to switch
> entirely. For example, I could have a xml file for production code and
> another for testing purposes.
>
> Also, another advantage is that the container takes care of ordering
> object creation for me. For example, if the object A, B and C needed to be
> injected on the object Y, I just have to declare each one of those objects
> on the configuration file, the container arranges the creation order for
> me.
>

I don't see what is special about this.  You can easily arrange instance
creation order with methods on the class-side of your domain classes.
Indeed, the GTTools are set up to work with in-Image sample data.  Look at
implementors of #sample and #example.
There was quite some bike-shedding over the naming convention (and I forget
the final result), but hopefully it provide the general idea...

http://forum.world.st/a-request-to-change-the-meaning-of-lt-example-gt-pragma-td4927360.html
http://forum.world.st/lt-example-gt-lt-examplar-gt-td4911728i20.html
http://forum.world.st/Existing-lt-script-gt-lt-example-gt-pragmas-and-new-GT-needs-td4814903i20.html

>
> I started, however, to question DI as a valid mechanisms because of it's
> complexities and other problems. The article from Fowler provides the
> service locator as an alternative which seems to me much simpler and
> completely fine solution for the problem.
>

If it seems suitable, then to quote Nike, just do it ;)

> So, to answer you question "Is it any more complicated than that?": In
> the DI approach, yes it can be, but I don't think so in the service locator
> approach.
>
> I am asking here because I wanted to know how people from Smalltalk deal
> with this problem. As it seems there is no standard approach, nor this is
> perceived as a problem...
>

DI or Service Locator are both "implementations" of your need.  Can we take
step backward to see what is your need?  To kick off, I hazard a guess at
some possible needs...

1.  To switch between configurations to use production data and test data ?
2.  To make this switch during CI testing and production deployment ?
3.  To switch from the command line ?
4.  Want the configuration to editable remotely? e.g. from a text editor?
?
...

> You think it is enough to do the wiring by hand?
>

I'm having trouble understanding this "by hand" concept.
Don't you create the xml configuration file by hand?
You can just as easily

> It is ok to use a service locator approach?  Or wouldn't you care about
> that?
>

If it works, its okay.

So very generally, I'd avoid starting with any external test data, so as to
not distract myself by that implementation.
I'd copy-paste some test data into the class-side-methods of the domain
classes and hack some instance creation code around them.
Build your first tests around those. Then later, consolidate them via an
InImageTestData object that you'll later replace with ExternalTestData

>
>
> but I'll add, it was so much simpler to understand without all that Java
>> typing boiler plate.
>
>
> Yeah, that's for sure! I am just used to read Java code.
>
> []s,
> Vitor
>
>
>
As an aside, try evaluting "Smalltalk tools inspect"
and debugging "Smalltalk tools browser open"

cheers -ben

Re: [Pharo-users] Bloc/Brick/Spec

On Tue, Jun 6, 2017 at 9:20 AM, Brad Selfridge 
wrote:

> I'm confused. I see the latest news and documentation about Bloc. Is Brick
> now dead and Bloc the default? I thought Brick was a layer on top of Bloc
> and Spec was layer on top on Brick? What is the direction now?
>
> Brad Selfridge
>
>
Can you link to this latest news?
cheers -ben

Re: [Pharo-users] How to use uFFI with String

2017-06-06 Thread Pierce Ng

On Sat, May 27, 2017 at 06:15:47AM -0700, horrido wrote:
> Yes, I did. I found it difficult to understand. It would be nice to have some
> clear examples in the documentation, for example, really simple and common
> situations such as a C function returning an integer in a
> passed-by-reference argument.

I've written such a thing:

  https://github.com/PierceNg/libffidemo

See these functions in the C library:

  int get_by_filling_pointer(demo_thing *pthing, int *pvalue)
  int get_by_returned_value(demo_thing *pthing)

Two follow-up blog posts:

  http://www.samadhiweb.com/blog/2016.03.12.demoffi.html
  http://www.samadhiweb.com/blog/2016.03.17.demoffi.html

I intend to modify my blog posts to contribute to the booklet, sometime in this
month of June.

Pierce

Re: [Pharo-users] Morphic or forking bug?

2017-06-06 Thread Sven Van Caekenberghe

You are mixing 3 different aspects: 

- how to update a UI from a background process
- how to maintain a background process over image save/open
- how to communicate between the 2

Safe UI updating has to happen using #step or #defer: and should be quick/short 
as not to block the UI. 

Although processes survive over image save/open (provided they did not become 
garbage), this is dangerous as they come up immediately (too soon) and will 
probably hold external resources (files/sockets/..) that will have changed (and 
result in a crash). It is better to manage this explicitly using #startUp and 
#shutDown.

Communication between the 2 should be protected using a semaphore.


Here is an example of a 'file watcher', a little window that shows the first 
line of a specific file, updating it every 3 seconds (silly and too resource 
intensive, it is just a demo). You can edit the file manually to modify the 
contents of the first line and see it being picked up in Pharo (within 3 
seconds).


Here is the code as 1 file/class in '_UnpackagedPackage':



MyFileWatcher.st
Description: Binary data



See the class side #initialize for the #startUp and #shutDown registration, 
sent to all instances as #start and #stop (a bit rude but good enough for the 
demo).

Instance side #initialize sets up the mutex that gets used in the #firstLine 
and #firstLine: accessors.

The actual process is in #run which calls #updateFirstLine

The UI updating is in #step which calls #updateFileLineDisplay

Subscribing to MorphDeleted via the announcer allows for the process to stop 
when the window closes.

The file watcher window and process survive an image save/open (i.e. they keep 
on working).


HTH,

Sven


> On 3 Jun 2017, at 15:44, horrido  wrote:
> 
> Okay, let me explain my application...
> 
> It displays a Morphic window containing lines of information that are
> updateable in real time on a periodic basis. As I indicated in the original
> post, the code skeleton is basically:
> 
> initA 
>   a := ((StringMorph contents: '') color: Color white) position: (0@0). 
>   m addMorph: a 
> 
> initialize 
>   f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'. 
>   m := ImageMorph new. 
>   m form: f. 
>   self initA. 
>   m openInWindowLabeled: 'Cranky'. 
>   delay := (Delay forSeconds: 5). 
>   [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork
> 
> Imagine that #initA creates many such StringMorphs, each displaying a
> different kind of information.
> 
> In the endless loop, imagine that instead of 'a contents: 0 asString', I'm
> updating all of the StringMorphs I created in #initA.
> 
> The need to do this in a separate thread is to prevent Pharo from being
> completely frozen during the 'delay wait', which is practically all the
> time!
> 
> Now, I did try Hilaire's suggestion to use Morphic's step protocol instead.
> But in my test scenario of closing the app/saving and exiting the
> image/restarting the image, repeatedly (in may take 10-20 times), it still
> causes the occasional segmentation fault.
> 
> So if the problem is updating a structure in the main thread from another
> process, then why did Hilaire's suggestion not solve the problem?
> 
> It seems to me, then, either way, it's an issue of multithreading...whether
> my way or Hilaire's way.
> 
> 
> 
> Sven Van Caekenberghe-2 wrote
>> Hi Horrido,
>> 
>> It is very hard to follow what you are exactly doing or trying to do.
>> 
>> Here is the simplest example I can think of that updates something in
>> Morphic on a regular basis.
>> 
>> StringMorph subclass: #MyClock
>>  instanceVariableNames: ''
>>  classVariableNames: ''
>>  package: '_UnpackagedPackage'
>> 
>> MyClock>>#initialize
>>  super initialize.
>>  self updateClock
>> 
>> MyClock>>#step
>>  self updateClock
>> 
>> MyClock>>#updateClock
>>  self contents: Time now printString
>> 
>> MyClock class>>#open
>>  "self open"
>>  
>>  ^ self new openInWindow
>> 
>> This inherits #stepTime as 1 second. If I open such a window and save my
>> image, it is still there when the image is restarted, with the clock still
>> working.
>> 
>> Updating (data structures in) the main UI process from another process is
>> dangerous. Saving such constructs is even more dangerous.
>> 
>> HTH,
>> 
>> Sven
>> 
>>> On 2 Jun 2017, at 15:54, horrido 
> 
>> horrido.hobbies@
> 
>>  wrote:
>>> 
>>> Sorry, I could be mistaken. I just checked my notes. The *0 asString*
>>> test
>>> failed once, but I've not been able to replicate it. I might've been
>>> working
>>> with an unclean image.
>>> 
>>> So perhaps it is related to Morphic, after all.
>>> 
>>> 
>>> horrido wrote
 Yup, they all fail. Interesting that 
>>> *
 0 asString
>>> *
 fails. This means it has NOTHING to do with Morphic (or Morphic being
 thread-unsafe).
 
 Ben Coman wrote
> On Wed, May 31, 2017 at 10:23 PM, horrido 
>>> 
> horrido.hobbies@
>>>

Re: [Pharo-users] Wiring objects, IoC and Service Locator

2017-06-06 Thread Vitor Medina Cruz

Thanks for the detailed answer ben :)

I will try to clarify a little: the question is how to loosely wire
objects, such as MovieLister to MovieFinder, so that changes in the wiring
can be made without effort. In Java, people use DI containers and xml files
or annotations to provide the wiring configuration, which is easy to switch
entirely. For example, I could have a xml file for production code and
another for testing purposes.

Also, another advantage is that the container takes care of ordering object
creation for me. For example, if the object A, B and C needed to be
injected on the object Y, I just have to declare each one of those objects
on the configuration file, the container arranges the creation order for
me.

I started, however, to question DI as a valid mechanisms because of it's
complexities and other problems. The article from Fowler provides the
service locator as an alternative which seems to me much simpler and
completely fine solution for the problem.

So, to answer you question "Is it any more complicated than that?": In the
DI approach, yes it can be, but I don't think so in the service locator
approach.

I am asking here because I wanted to know how people from Smalltalk deal
with this problem. As it seems there is no standard approach, nor this is
perceived as a problem... You think it is enough to do the wiring by hand?
It is ok to use a service locator approach? Or wouldn't you care about that?

but I'll add, it was so much simpler to understand without all that Java
> typing boiler plate.

Yeah, that's for sure! I am just used to read Java code.

[]s,
Vitor

On Mon, Jun 5, 2017 at 9:46 PM, Ben Coman  wrote:

>
>
> On Tue, Jun 6, 2017 at 5:11 AM, Stephane Ducasse 
> wrote:
>
>> Tx ben.
>> When I see all this complexity for something that looks not that complex:
>> I prefer to pass the class and get done.
>> May be I missed something obvious... but when I see something too complex
>> I start to get worried.
>>
>> I think that thinking about the contract between classes at runtime is
>> important and to me a MovieLister should be using at runtime and instance
>> of the *Finder*
>> Now needing an extra class just to set this should really be evaluated
>> with the tradeoff: "flexibility win" (our simple solution is still really
>> flexible - I decide when I want to pass the correct finder) vs. the code
>> and conceptual bloat.
>>
>>
>> I'm happy not to face the hyper super over engineering of Java
>> "solutions".
>>
>> I like the "Of course this just shifts the burden a tad, we still have
>> to get the locator into the lister"
>> but the solution is super simple let us use another "Singleton and a
>> Factory" :)
>>
>> Stef
>>
>> On Mon, Jun 5, 2017 at 8:43 PM, Ben Coman  wrote:
>>
>>>
>>>
>>> On Tue, Jun 6, 2017 at 1:26 AM, Vitor Medina Cruz 
>>> wrote:
>>>
 Thanks for the answer Ben and Stephane.

 I already read A Mentoring Course on Smalltalk, Valloud, there is
 nothing there I could use in this case :( . I will look after for The
 Design Patterns Smalltalk Companion. Most of the sources provided I already
 know of or went in the same lines lines of what I have already found.

 About TDD, I am experienced with the discipline and have tested it on
 Pharo living system already, but I could not understand how this is related
 with object wiring, DI and service locator.

>>>
>>> I guess I don't properly understand your need and those topics.  That
>>> was my quick pass.  Now if I take the time to actually read Fowler's long
>>> article
>>>
>>> "the inversion is about how they lookup a plugin implementation ... to
>>> ensure that any user of a plugin follows some convention that allows a
>>> separate assembler module to inject the implementation into the lister."
>>>
>>> "The basic idea of the Dependency Injection is to have a separate
>>> object, an assembler, that populates a field in the lister class with an
>>> appropriate implementation for the finder interface. There are three main
>>> styles of dependency injection. The names I'm using for them are
>>> Constructor Injection, Setter Injection, and Interface Injection."
>>>
>>> Now there was too much syntactical noise in those Java examples for me
>>> to think clearly, so I converted them all to Smalltalk.
>>>
>>>
>>> ##CONSTRUCTOR INJECTION
>>>
>>> Object subclass: MovieLister
>>> instanceVariables: 'finder'
>>>
>>>
>>> MovieLister class >> newWith: aFinder
>>> ^ self basicNew initializeWith: aFinder
>>>
>>> MovieLister >> initializeWith: aFinder
>>> finder := aFinder
>>>
>>>
>>> ColonMovieFinder class >> newWith: aFilename
>>> ^ self basicNew initializeWith: aFilename
>>>
>>> ColonMovieFinder >> initializeWith: aFilename
>>> filename := aFilename.
>>>
>>>
>>> ConstructorInjectionContainer >> new
>>> container := DefaultContainer new.  "the article doesn't specify

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium New Bronze Member: Palantir Solutions

2017-06-06 Thread Tudor Girba

Excellent news!

Doru


> On Jun 6, 2017, at 2:53 PM, Marcus Denker  wrote:
> 
> The Pharo Consortium is very happy to announce that Palantir Solutions
> has joined the Consortium as a Bronze Member.
> 
> About
> - Palantir Solutions: https://www.petrovr.com
> - Pharo Consortium: http://consortium.pharo.org
> 
> The goal of the Pharo Consortium is to allow companies and institutions to
> support the ongoing development and future of Pharo.
> 
> Individuals can support Pharo via the Pharo Association:
> 
> - http://association.pharo.org
> 

--
www.tudorgirba.com
www.feenk.com

"Every thing should have the right to be different."

[Pharo-users] [ANN] Pharo Consortium New Bronze Member: Palantir Solutions

2017-06-06 Thread Marcus Denker

The Pharo Consortium is very happy to announce that Palantir Solutions
has joined the Consortium as a Bronze Member.

About
- Palantir Solutions: https://www.petrovr.com
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to
support the ongoing development and future of Pharo.

Individuals can support Pharo via the Pharo Association:

- http://association.pharo.org

Re: [Pharo-users] Porting Transducers to Pharo

2017-06-06 Thread p...@highoctane.be

Check

https://medium.com/@i.oleks/interface-for-selecting-data-from-a-dataset-d7c6b5fb378f

https://medium.com/@i.oleks/an-example-of-test-driven-development-c9ce033f05ef

Loading a dataframe from a dataset and then using transducers for a
transformation pipeline would be great.

DataFrame is part of Polymath.

https://github.com/PolyMathOrg/PolyMath
http://www.smalltalkhub.com/#!/~PolyMath/PolyMath


Phil

On Tue, Jun 6, 2017 at 1:09 PM, Steffen Märcker  wrote:

> Hi Phil,
>
> Coupling this with Olek's work on the DataFrame could really come handy.
>>
>
> I am new to this list. Could you please elaborate?
>
> Cheers!
> Steffen
>
>
>
> On Mon, Jun 5, 2017 at 9:14 AM, Stephane Ducasse 
>> wrote:
>>
>> Hi Steffen
>>>
>>>
>>> > The short answer is that the compact notation turned out to work much
>>> better
>>> > for me in my code, especially, if multiple transducers are involved.
>>> But
>>> > that's my personal taste. You can choose which suits you better. In
>>> fact,
>>> >
>>> >   1000 take.
>>> >
>>> > just sits on top and simply calls
>>> >
>>> >   Take number: 1000.
>>>
>>> To me this is much much better.
>>>
>>>
>>> > If the need arises, we could of course factor the compact notation out
>>> into
>>> > a separate package.
>>> Good idea
>>>
>>>  Btw, would you prefer (Take n: 1000) over (Take number:
>>> > 1000)?
>>>
>>> I tend to prefer explicit selector :)
>>>
>>>
>>> > Damien, you're right, I experimented with additional styles. Right now,
>>> we
>>> > already have in the basic Transducer package:
>>> >
>>> >   (collection transduce: #squared map * 1000 take. "which is equal to"
>>> >   (collection transduce: #squared map) transduce: 1000 take.
>>> >
>>> > Basically, one can split #transduce:reduce:init: into single calls of
>>> > #transduce:, #reduce:, and #init:, depending on the needs.
>>> > I also have an (unfinished) extension, that allows to write:
>>> >
>>> >   (collection transduce map: #squared) take: 1000.
>>>
>>> To me this is much mre readable.
>>> I cannot and do not want to use the other forms.
>>>
>>>
>>> > This feels familiar, but becomes a bit hard to read if more than two
>>> steps
>>> > are needed.
>>> >
>>> >   collection transduce
>>> >map: #squared;
>>> >take: 1000.
>>>
>>> Why this is would hard to read. We do that all the time everywhere.
>>>
>>>
>>> > I think, this alternative would reads nicely. But as the message chain
>>> has
>>> > to modify the underlying object (an eduction), very snaky side effects
>>> may
>>> > occur. E.g., consider
>>> >
>>> >   eduction := collection transduce.
>>> >   squared  := eduction map: #squared.
>>> >   take := squared take: 1000.
>>> >
>>> > Now, all three variables hold onto the same object, which first squares
>>> all
>>> > elements and than takes the first 1000.
>>>
>>> This is because the programmer did not understand what he did. No?
>>>
>>>
>>>
>>> Stef
>>>
>>> PS: I played with infinite stream and iteration back in 1993 in CLOS.
>>> Now I do not like to mix things because it breaks my flow of thinking.
>>>
>>>
>>> >
>>> > Best,
>>> > Steffen
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Am .06.2017, 21:28 Uhr, schrieb Damien Pollet
>>> > :
>>> >
>>> >> If I recall correctly, there is an alternate protocol that looks more
>>> like
>>> >> xtreams or the traditional select/collect iterations.
>>> >>
>>> >> On 2 June 2017 at 21:12, Stephane Ducasse 
>>> wrote:
>>> >>
>>> >>> I have a design question
>>> >>>
>>> >>> why the library is implemented in functional style vs messages?
>>> >>> I do not see why this is needed. To my eyes the compact notation
>>> >>> goes against readibility of code and it feels ad-hoc in Smalltalk.
>>> >>>
>>> >>>
>>> >>> I really prefer
>>> >>>
>>> >>> square := Map function: #squared.
>>> >>> take := Take number: 1000.
>>> >>>
>>> >>> Because I know that I can read it and understand it.
>>> >>> From that perspective I prefer Xtreams.
>>> >>>
>>> >>> Stef
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Wed, May 31, 2017 at 2:23 PM, Steffen Märcker 
>>> wrote:
>>> >>>
>>>  Hi,
>>> 
>>>  I am the developer of the library 'Transducers' for VisualWorks. It
>>> was
>>>  formerly known as 'Reducers', but this name was a poor choice. I'd
>>> like
>>>  to
>>>  port it to Pharo, if there is any interest on your side. I hope to
>>> learn
>>>  more about Pharo in this process, since I am mainly a VW guy. And
>>> most
>>>  likely, I will come up with a bunch of questions. :-)
>>> 
>>>  Meanwhile, I'll cross-post the introduction from VWnc below. I'd be
>>> very
>>>  happy to hear your optinions, questions and I hope we can start a
>>>  fruitful
>>>  discussion - even if there is not Pharo port yet.
>>> 
>>>  Best, Steffen
>>> 
>>> 
>>> 
>>>  Transducers are building blocks

Re: [Pharo-users] Porting Transducers to Pharo

2017-06-06 Thread p...@highoctane.be

Hi Steffen,

I am willing to help you create the package in SmalltalkHub or Github based
on your files/changeset.

Do you have a github and/or SmalltalkHub account?

Best,
Phil


On Tue, Jun 6, 2017 at 1:08 PM, Steffen Märcker  wrote:

> Hi!
>
> If the need arises, we could of course factor the compact notation out into
>>> a separate package.
>>>
>> Good idea
>> [...] I do not want to help promoting a syntax that alienates me (and
>> others because other people reported the saem to me).
>>
>
> I understand. Btw, I'd really, really appreciate if others post their
> thoughts and feedback here as well. Discussion helps moving things forward.
> =)
>
>
>   (collection transduce map: #squared) take: 1000.
>>>
>>
>> To me this is much more readable.
>>
>
> Well, I'll provide that extension once it is finished.
>
> I cannot and do not want to use the other forms.
>>
>
>
>   collection transduce
>>>map: #squared;
>>>take: 1000.
>>>
>>> But as the message chain has to modify the underlying object
>>> (an eduction), very snaky side effects my occur. E.g., consider
>>>
>>>   eduction := collection transduce.
>>>   squared  := eduction map: #squared.
>>>   take := squared take: 1000.
>>>
>>> Now, all three variables hold onto the same object, which first squares
>>> all elements and than takes the first 1000.
>>>
>>
>> This is because the programmer did not understand what he did. No?
>>
>
> Sure. ;-) Nevertheless, it would be very hard to debug. All of which are
> the reasons I wouldn't implement that variant. ;-)
>
>
> PS: I played with infinite stream and iteration back in 1993 in CLOS.
>> Now I do not like to mix things because it breaks my flow of thinking.
>>
>
>
> I am not sure whether I understand what your mean by mixing. Concerning
> transducers, the ability to handle infinite sources in only a (natural)
> side-effect of the ability to finish reductions before all elements are
> processed, e.g., like #detect: and such.
>
> Best, Steffen
>
>
>
>
>
>

Re: [Pharo-users] Creating a BaselineOf from a ConfigurationOf>>#baselineXyz:

2017-06-06 Thread Nicolai Hess

Hi Sean,

2017-06-04 5:48 GMT+02:00 Sean P. DeNigris :

> I'm trying to write a rewrite rule, but can't quite get it.
>
> I first want to remove `spec blessing: #baseline.`
>
> I tried the following with no effect:
>
> RBParseTreeRewriter new
> replace: '`@expr blessing: `#lit'
> with: '';
> executeTree: methodTree;
> tree.
>

This works for me, but ...


>
> NB: If I try to edit the expression instead of remove, by passing something
> like '`@expr assert: `#lit' for #with:, it works
>
> What am I missing here?
>
> Thanks!
>
>

keep in mind some odds about the caching on ast nodes.

Working with the tree rewriter directly on the method ast
(MyClass>>#myMethod) ast

- will modify the "cached" method ast, that means,  on code browser,  you
do not see the change.
- the #source method of the ast, again only shows a cached source
  (MyClass>>#myMethod) ast source -> "old source"
- printing the formatted code will finally step into the (modified) method
source nodes
  (MyClass>>#myMethod) ast formattedCode -> "new source code"










>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/
> Creating-a-BaselineOf-from-a-ConfigurationOf-baselineXyz-tp4949192.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Analyzing Fuel Problem

2017-06-06 Thread Mariano Martinez Peck

Hi Sean,

Sorry for the delay on the answer. Yes, that's a good spot. Another thing I
usually do is to put a halt in FLSerialization >> run. Just after
#analysisStep for example, and then inspect the local variables.

Also, if you want to understand WHY an object is getting in, then you can
also halt in #trace and #privateTrace: from FLAnalysis. That way you
monitor which objects gets pushed into the analysis stack. You can do
something like

self haltIf: [ anObject whateverConditionToHaltOnDesiredObject = true ].

Finally, there are more tools for debugging this kind of issue, but I don't
know their state. You can read more about them here [1].

Best regards,

[1]
https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Debugging

On Fri, Jun 2, 2017 at 10:26 PM, Sean P. DeNigris 
wrote:

> I had an object graph that was pulling in all sorts of unrelated classes
> when
> serialized with Fuel. I was trying to find the offending object, and came
> up
> with the following:
> ```
> (FLAnalyzer newDefault analysisFor: root) clusterization globalsBucket
> ```
>
> This worked, but I was wondering if that's "the right way" to do it...
>
> Thanks.
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/
> Analyzing-Fuel-Problem-tp4949104.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

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

Re: [Pharo-users] Porting Transducers to Pharo - Name Clash


Hi,

I found some name clash with the message #reduce: in Pharo. It is already  
declared in SequencableCollection. Additionally, Collection>>fold: just  
calls #reduce:, which makes the difference between folding and reducing a  
bit unclear.


How should I handle this situation? I see the following options:
- I could simply solve the situation at runtime depending on the argument  
(e.g., using double-dispatching).
- I could check whether it might be possible to separate #fold: and  
#reduce: with the semantics:

  - reduce: starts with an initial value and the first collection item.
  - fold: uses no initial value and starts with the first two items.

In the Transducers library, there are two variants of reduce:
- #reduce:init: reduce using a block and an intial value
- #reduce: reduce using a block that carries an intial value or an  
initializer block.


Ciao,
Steffen


Am .05.2017, 14:23 Uhr, schrieb Steffen Märcker :


Hi,

I am the developer of the library 'Transducers' for VisualWorks. It was  
formerly known as 'Reducers', but this name was a poor choice. I'd like  
to port it to Pharo, if there is any interest on your side. I hope to  
learn more about Pharo in this process, since I am mainly a VW guy. And  
most likely, I will come up with a bunch of questions. :-)


Meanwhile, I'll cross-post the introduction from VWnc below. I'd be very  
happy to hear your optinions, questions and I hope we can start a  
fruitful discussion - even if there is not Pharo port yet.


Best, Steffen



Transducers are building blocks that encapsulate how to process elements
of a data sequence independently of the underlying input and output  
source.




# Overview

## Encapsulate
Implementations of enumeration methods, such as #collect:, have the logic
how to process a single element in common.
However, that logic is reimplemented each and every time. Transducers  
make

it explicit and facilitate re-use and coherent behavior.
For example:
- #collect: requires mapping: (aBlock1 map)
- #select: requires filtering: (aBlock2 filter)


## Compose
In practice, algorithms often require multiple processing steps, e.g.,
mapping only a filtered set of elements.
Transducers are inherently composable, and hereby, allow to make the
combination of steps explicit.
Since transducers do not build intermediate collections, their  
composition

is memory-efficient.
For example:
- (aBlock1 filter) * (aBlock2 map)   "(1.) filter and (2.) map elements"


## Re-Use
Transducers are decoupled from the input and output sources, and hence,
they can be reused in different contexts.
For example:
- enumeration of collections
- processing of streams
- communicating via channels



# Usage by Example

We build a coin flipping experiment and count the occurrence of heads and
tails.

First, we associate random numbers with the sides of a coin.

 scale := [:x | (x * 2 + 1) floor] map.
 sides := #(heads tails) replace.

Scale is a transducer that maps numbers x between 0 and 1 to 1 and 2.
Sides is a transducer that replaces the numbers with heads an tails by
lookup in an array.
Next, we choose a number of samples.

 count := 1000 take.

Count is a transducer that takes 1000 elements from a source.
We keep track of the occurrences of heads an tails using a bag.

 collect := [:bag :c | bag add: c; yourself].

Collect is binary block (reducing function) that collects events in a  
bag.
We assemble the experiment by transforming the block using the  
transducers.


 experiment := (scale * sides * count) transform: collect.

   From left to right we see the steps involved: scale, sides, count and
collect.
Transforming assembles these steps into a binary block (reducing  
function)

we can use to run the experiment.

 samples := Random new
   reduce: experiment
   init: Bag new.

Here, we use #reduce:init:, which is mostly similar to #inject:into:.
To execute a transformation and a reduction together, we can use
#transduce:reduce:init:.

 samples := Random new
   transduce: scale * sides * count
   reduce: collect
   init: Bag new.

We can also express the experiment as data-flow using #<~.
This enables us to build objects that can be re-used in other  
experiments.


 coin := sides <~ scale <~ Random new.
 flip := Bag <~ count.

Coin is an eduction, i.e., it binds transducers to a source and
understands #reduce:init: among others.
Flip is a transformed reduction, i.e., it binds transducers to a reducing
function and an initial value.
By sending #<~, we draw further samples from flipping the coin.

 samples := flip <~ coin.

This yields a new Bag with another 1000 samples.



# Basic Concepts

## Reducing Functions

A reducing function represents a single step in processing a data  
sequence.

It takes an accumulated result and a value, and returns a new accumulated
result.
For example:

 collect := [:col :e |

Re: [Pharo-users] Porting Transducers to Pharo

Hi Phil,

Coupling this with Olek's work on the DataFrame could really come handy.

I am new to this list. Could you please elaborate?

Cheers!
Steffen

On Mon, Jun 5, 2017 at 9:14 AM, Stephane Ducasse  

wrote:

Hi Steffen

> The short answer is that the compact notation turned out to work much
better
> for me in my code, especially, if multiple transducers are involved.  
But
> that's my personal taste. You can choose which suits you better. In  
fact,

>
>   1000 take.
>
> just sits on top and simply calls
>
>   Take number: 1000.

To me this is much much better.

> If the need arises, we could of course factor the compact notation out
into
> a separate package.
Good idea

 Btw, would you prefer (Take n: 1000) over (Take number:
> 1000)?

I tend to prefer explicit selector :)

> Damien, you're right, I experimented with additional styles. Right  
now,

we
> already have in the basic Transducer package:
>
>   (collection transduce: #squared map * 1000 take. "which is equal to"
>   (collection transduce: #squared map) transduce: 1000 take.
>
> Basically, one can split #transduce:reduce:init: into single calls of
> #transduce:, #reduce:, and #init:, depending on the needs.
> I also have an (unfinished) extension, that allows to write:
>
>   (collection transduce map: #squared) take: 1000.

To me this is much mre readable.
I cannot and do not want to use the other forms.

> This feels familiar, but becomes a bit hard to read if more than two
steps
> are needed.
>
>   collection transduce
>map: #squared;
>take: 1000.

Why this is would hard to read. We do that all the time everywhere.

> I think, this alternative would reads nicely. But as the message chain
has
> to modify the underlying object (an eduction), very snaky side effects
may
> occur. E.g., consider
>
>   eduction := collection transduce.
>   squared  := eduction map: #squared.
>   take := squared take: 1000.
>
> Now, all three variables hold onto the same object, which first  
squares

all
> elements and than takes the first 1000.

This is because the programmer did not understand what he did. No?

Stef

PS: I played with infinite stream and iteration back in 1993 in CLOS.
Now I do not like to mix things because it breaks my flow of thinking.

>
> Best,
> Steffen
>
>
>
>
>
> Am .06.2017, 21:28 Uhr, schrieb Damien Pollet
> :
>
>> If I recall correctly, there is an alternate protocol that looks more
like
>> xtreams or the traditional select/collect iterations.
>>
>> On 2 June 2017 at 21:12, Stephane Ducasse 
wrote:
>>
>>> I have a design question
>>>
>>> why the library is implemented in functional style vs messages?
>>> I do not see why this is needed. To my eyes the compact notation
>>> goes against readibility of code and it feels ad-hoc in Smalltalk.
>>>
>>>
>>> I really prefer
>>>
>>> square := Map function: #squared.
>>> take := Take number: 1000.
>>>
>>> Because I know that I can read it and understand it.
>>> From that perspective I prefer Xtreams.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 31, 2017 at 2:23 PM, Steffen Märcker 
wrote:
>>>
 Hi,

 I am the developer of the library 'Transducers' for VisualWorks. It
was
 formerly known as 'Reducers', but this name was a poor choice. I'd
like
 to
 port it to Pharo, if there is any interest on your side. I hope to
learn
 more about Pharo in this process, since I am mainly a VW guy. And  
most

 likely, I will come up with a bunch of questions. :-)

 Meanwhile, I'll cross-post the introduction from VWnc below. I'd be
very
 happy to hear your optinions, questions and I hope we can start a
 fruitful
 discussion - even if there is not Pharo port yet.

 Best, Steffen

 Transducers are building blocks that encapsulate how to process
elements
 of a data sequence independently of the underlying input and output
 source.

 # Overview

 ## Encapsulate
 Implementations of enumeration methods, such as #collect:, have the
 logic
 how to process a single element in common.
 However, that logic is reimplemented each and every time.  
Transducers

 make
 it explicit and facilitate re-use and coherent behavior.
 For example:
 - #collect: requires mapping: (aBlock1 map)
 - #select: requires filtering: (aBlock2 filter)

 ## Compose
 In practice, algorithms often require multiple processing steps,  
e.g.,

 mapping only a filtered set of elements.
 Transducers are inherently composable, and hereby, allow to make  
the

 combination of steps explicit.
 Since transducers do not build intermediate collections, their
 composition
 is memory-efficient.
 For example:
 - (aBlock1 filter) * (aBlock2 map)   "(1.) filter and (2.) map
elements"

 ##

Re: [Pharo-users] Porting Transducers to Pharo


Hi!

If the need arises, we could of course factor the compact notation out  
into

a separate package.

Good idea
[...] I do not want to help promoting a syntax that alienates me (and
others because other people reported the saem to me).


I understand. Btw, I'd really, really appreciate if others post their  
thoughts and feedback here as well. Discussion helps moving things  
forward. =)




  (collection transduce map: #squared) take: 1000.


To me this is much more readable.


Well, I'll provide that extension once it is finished.


I cannot and do not want to use the other forms.




  collection transduce
   map: #squared;
   take: 1000.

But as the message chain has to modify the underlying object
(an eduction), very snaky side effects my occur. E.g., consider

  eduction := collection transduce.
  squared  := eduction map: #squared.
  take := squared take: 1000.

Now, all three variables hold onto the same object, which first squares  
all elements and than takes the first 1000.


This is because the programmer did not understand what he did. No?


Sure. ;-) Nevertheless, it would be very hard to debug. All of which are  
the reasons I wouldn't implement that variant. ;-)




PS: I played with infinite stream and iteration back in 1993 in CLOS.
Now I do not like to mix things because it breaks my flow of thinking.



I am not sure whether I understand what your mean by mixing. Concerning  
transducers, the ability to handle infinite sources in only a (natural)  
side-effect of the ability to finish reductions before all elements are  
processed, e.g., like #detect: and such.


Best, Steffen

Re: [Pharo-users] Porting Transducers to Pharo