Re: [Pharo-users] PetitParser problem with plus

[Jan Kurš]

Exactly...

This happens so often that we should add some warning somewhere in these
cases


Cheers,
Jan

On 18 December 2014 at 08:36, Guillaume Larcheveque <
guillaume.larcheve...@gmail.com> wrote:
>
> So you just have to remove the #star in notA or replace it by #plus to
> makes it succeed only when it consume at least one character
>
> 2014-12-18 7:54 GMT+01:00 Guillaume Larcheveque <
> guillaume.larcheve...@gmail.com>:
>>
>> With x, x it will only go to 2 level deep.
>>
>> With the plus you allow to go as far as the x rule succeed and your x
>> rule always succeed because notA always succeed due to the star without
>> consuming anything so you fall into infinite loop.
>>
>> 2014-12-18 6:47 GMT+01:00 James Foster :
>>>
>>> There is something about plus that I don’t understand. In the following
>>> code if I parse for (x , x) then I get what I expect. If I parse for (x
>>> plus) then the image hangs. What am I doing wrong?
>>>
>>> James
>>>
>>> | a notA x y |
>>> a := $a asParser.
>>> notA := $a asParser negate star flatten.
>>> x := a / notA.
>>> y := x , x. “works fine”
>>> y := x plus. “never finishes”
>>> ^y end parse: 'ab’.
>>>
>>>
>>>
>>
>> --
>> *Guillaume Larcheveque*
>>
>>
>
> --
> *Guillaume Larcheveque*
>
>

[Pharo-users] Question about Morphic in Pharo 4

[nacho]

Hi folks,
I'm doing some project in Morphic in Pharo 3. I was wondering if big changes
are expected in Moprhic in Pharo 4 or if it will remain relatively
unchanged.
Thanks in advance.
Nacho




-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: 
http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] PetitParser problem with plus

[James Foster]

That did it and it makes sense. Thanks so much!

> On Dec 17, 2014, at 11:36 PM, Guillaume Larcheveque 
>  wrote:
> 
> So you just have to remove the #star in notA or replace it by #plus to makes 
> it succeed only when it consume at least one character
> 
> 2014-12-18 7:54 GMT+01:00 Guillaume Larcheveque 
> mailto:guillaume.larcheve...@gmail.com>>:
> With x, x it will only go to 2 level deep.
> 
> With the plus you allow to go as far as the x rule succeed and your x rule 
> always succeed because notA always succeed due to the star without consuming 
> anything so you fall into infinite loop.
> 
> 2014-12-18 6:47 GMT+01:00 James Foster  >:
> There is something about plus that I don’t understand. In the following code 
> if I parse for (x , x) then I get what I expect. If I parse for (x plus) then 
> the image hangs. What am I doing wrong?
> 
> James
> 
> | a notA x y |
> a := $a asParser.
> notA := $a asParser negate star flatten.
> x := a / notA.
> y := x , x. “works fine”
> y := x plus. “never finishes”
> ^y end parse: 'ab’.
> 
> 
> 
> 
> -- 
> Guillaume Larcheveque
> 
> 
> 
> -- 
> Guillaume Larcheveque
> 

Re: [Pharo-users] Question about Morphic in Pharo 4

[kilon alios]

No the improvements are gradual and try to clean up some of the design of
Morphic but as you can imagine backward compatibility has to be retained
because there is loads of Pharo tools, apps , code and libraries that rely
on Morphic and Morphic's design. Even if Morphic is replaced at some point
it will be a very gradual process and still some compatibility will be
retained to keep things familiar for experience pharo coders.

Most of all Morphic is by far the biggest and most complex pharo library so
producing a replacement it wont be a walk in the park. So yes you can rely
on the fact that things will stay not exactly the same but pretty similar
for a very very long time. If I had to say an estimate I would say at least
10 years down the road.

On Thu, Dec 18, 2014 at 4:28 PM, nacho <0800na...@gmail.com> wrote:
>
> Hi folks,
> I'm doing some project in Morphic in Pharo 3. I was wondering if big
> changes
> are expected in Moprhic in Pharo 4 or if it will remain relatively
> unchanged.
> Thanks in advance.
> Nacho
>
>
>
>
> -
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.
> --
> View this message in context:
> http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

[Pharo-users] ¿Tagged branch development support in Pharo/Moose?

[Offray Vladimir Luna Cárdenas]

Hi,

I wonder if there is something like fossil tagged branches and some 
visual clues to know to which branch commit and how to do merges. See 
for example at:


http://fossil-scm.org/index.html/timeline?y=ci

I have read the PBE2 book on monticello development and is easy to go to 
a previous version, made some changes and then merge from there, but 
seems not much "elegant". I would expect something like the possibility 
to commit to a particular branch with a particular name o create one if 
none is named like that, in a similar way to fossil. Also I would expect 
some tree-like visualization of the branches, commits and merges.


There is something that can support this development workflow?

Thanks,

Offray

[Pharo-users] Question about SUnit

[Demian Schkolnik]

Greetings.

I have to do a bunch of tests, where the initial set up is quite costly
(launching ROS system and a bunch of nodes). Therefore, I don't want to set
it up each time before a test (like with the standard setUp function). How
can I make it so that the setUp function is called only once overall before
ALL tests?  (And aditionally, so that the tearDown function is called only
once after all tests have run?)

Thank you all in advance,
best,

Re: [Pharo-users] Question about SUnit

[Sven Van Caekenberghe]

You need to check out TestResource (see it's class comment), it was designed 
specifically for that purpose.

> On 18 Dec 2014, at 20:00, Demian Schkolnik  wrote:
> 
> Greetings.
> 
> I have to do a bunch of tests, where the initial set up is quite costly 
> (launching ROS system and a bunch of nodes). Therefore, I don't want to set 
> it up each time before a test (like with the standard setUp function). How 
> can I make it so that the setUp function is called only once overall before 
> ALL tests?  (And aditionally, so that the tearDown function is called only 
> once after all tests have run?)
> 
> Thank you all in advance,
> best,

Re: [Pharo-users] Question about Morphic in Pharo 4

[stepharo]

Hi

You never know but in general we pay attention not to break for the 
shake of it.

Then Morphic is several things
- low level
- widgets
- polymorph
So this is difficult to be fully affirmative. What I can say is that we 
did not change much.

stef
Le 18/12/14 15:28, nacho a écrit :

Hi folks,
I'm doing some project in Morphic in Pharo 3. I was wondering if big changes
are expected in Moprhic in Pharo 4 or if it will remain relatively
unchanged.
Thanks in advance.
Nacho




-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: 
http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] New Pharo Collections

[stepharo]

In the Design Pattern iterator there are some nice examples about iterators.

Stef
Le 17/12/14 08:49, Clément Bera a écrit :



2014-12-17 7:42 GMT+01:00 Damien Cassou >:



Le 16 déc. 2014 22:48, "dboeren" mailto:boer...@gmail.com>> a écrit :.
> Off the top of my head, I would be interested in support for
"slices"
> meaning taking being able to treat a subset of a larger
OrderedCollection as
> its own OrderedCollection rather than using copyFrom:to: to create a
> duplicate object to work with.  It seems to me that this would
be a more
> efficient method and should not be difficult to implement I think.

Here is an email I sent about that :

I see you are working on new collections for Pharo. That's great news,
I'm convinced we can do much better (even if what we already have is
already much better than what can be found in most other languages).
One thing you could work on is the notion of iterator. There are
plenty of ways to iterate over a collection:

1/ from the first to the last item
2/ from the last to the first
3/ from the 2nd item to the 5th
4/ only even items (2, 4, 6, ...)
5/ ...

Currently, we have to create new collections to iterate in strange
ways. For example, to iterate from the last to the first item, we
create a new collection by sending #reversed to the original
collection. I think that is bad because it creates a copy and that
should not be necessary.

I don't understand that example. #reverseDo: do not create a copy and 
do not send reversed. To iterate over items from last to first I 
always do, as recommended in Smalltalk best practice pattern:


mySequenceableCollection reverseDo: [:item | .. ].

#reverseDo: is implemented on SequenceableCollection but iterating 
from last to first item does not make sense in the case of non 
sequenceable collection.


What we miss is the notion of iterator. An
iterator is an object that is specialized in iterating over any kind
of collection and has methods like #select:, #reject:, #allSatisfy:.
>From a collection, you can access different kinds of iterators
(reusing the same ordering as before):

1/ aCollection iterator
2/ aCollection reverseIterator
3/ aCollection from: 2 to: 5
4/ aCollection iterator select: [ :each | each isEven ] --> that
returns an iterator as well, so you can call #select:/#reject:
multiple times without creating any intermediate collection
5/ ...

That makes sense and would be lovely. What is the syntax for multiple 
operations ? Have you already think and find something nice about it ?


aCollection iterator
select: [ :each | each isOdd ];
reject: [ :each | each is isPrime ];
iterate

???

Of course there are backward compatibility issue which needs to be 
very well adressed here or one would crash every single framework in 
the system.


Lukas Renggli implemented a prototype that looks really nice but is
unfinished:
http://source.lukas-renggli.ch/unsorted/Container-lr.7.mcz.

I think the notion of Sequences in Clojure is very related as well.
Sequence functions are very generic and can be applied to any kind of
collection. http://clojure.org/sequences

Re: [Pharo-users] Question about Morphic in Pharo 4

[Daniel Lyons]

> On Dec 18, 2014, at 3:31 PM, stepharo  wrote:
> 
> Hi
> 
> You never know but in general we pay attention not to break for the shake of 
> it.
> Then Morphic is several things
>- low level
>- widgets
>- polymorph
> So this is difficult to be fully affirmative. What I can say is that we did 
> not change much.

Not the OP, but I've been confused about the history and future plan for some 
time. My impression is that Morphic must have started out as a small and 
beautiful core. Otherwise you wouldn't find so many people talking about how 
amazing it was in writings dated 10 years ago and earlier. It must have been 
much faster and easier to work with than the earlier MVC. Then I guess it grew 
rapidly and radically out of control and became this monstrosity sitting in the 
Squeak image, which has been pared down significantly in the Pharo image but is 
still basically huge. Squeak mostly evolved by shared changes to the image, so 
there was no concept of separate packages adding this or that method to this 
system class, so everything eventually wound up depending on everything. As our 
infrastructure is inherited, we inherit this problem, even as we go about 
breaking everything down and simplifying it, there is a long way to go to get 
back to the original small and beautiful core—and that may not even really be a 
goal for Pharo and Morphic. Is this fair and accurate?

I have also heard that Morphic made more sense in its original habitat in Self, 
because you really could just clone a UI component and start customizing it, 
because Self only has instances, no classes. The "direct manipulation" argument 
is slightly sabotaged by the intrusion of a class hierarchy and textual coding. 
I'm just regurgitating a wisp of a memory though, I don't know if anybody who 
used it a lot would agree or not. (I'm not sure how one is able to make 
comprehensive principled changes in such a system, but that's an unnecessary 
diversion.) It seems to me that as Morphic halos get harder to get access to, 
direct manipulation becomes harder to effect; on the other hand, halos are 
probably a lot more confusing to beginners than helpful to anyone. Comments?

From there I'm not quite sure what Polymorph is and what its development 
status/future outlook are like. Is it actively developed and are we happy with 
people building new stuff with it? Seems like it was the preferred UI paradigm 
a few years ago but now we have Spec. Spec seems to be promising non-Morphic 
backends, is that an active development interest and if so what targets are 
being explored? Historically, Morphic itself seems to promise multiple backends 
(the comment on Canvas says "A canvas is a two-dimensional medium on which 
morphs are drawn in a device-independent manner"), did that ever come to 
fruition, or did they just mean it supported different kinds of monitors?

In the old books I see a lot of mentions of things like "pluggable" widgets, 
and in the image I see things like PluggableTextMorph. Following the Spec 
tutorial (which is excellent, by the way!), it feels like I have a lot of 
manual copying around of data in whenTextChanged: handlers. In fact, the old 
books also talk about the changed/changed:/changed:with: observer system, which 
I see is still in the image but it's not clear to me if any of these systems 
make use of that or if this whole system is considered deprecated. My suspicion 
is that it is deprecated because there is NewValueHolder. Is it?

I'm mostly asking for history as I try to get my bearings and not trying to 
deprecate anyone or anything, so if anything in the above is offensive, it is 
an accident, please correct me.

Thanks,

— 
Daniel Lyons