Monticello ad distribution

Hi,

I'm trying to get into Monticello usage right now.
I'm using Magritte and MagritteGlorp for my project.

I loaded all packages for magritte from lukas' site.
Then I installed MagritteGlorp from squeaksource which
has an own version of Magritte-Model. Now I did a change
to Magritte-Model myself. Where do I put the package?

I would like to put it on the official (lukas') repo. But
I'm not sure how to do it. Packages have information
about the package version they are based on. But the
version numbers in MagritteGlorp aren't present in
the official repository. What would be the result of
putting my changed version on the official repo?

Is there a standard workflow for this? I doubt that
package have any reference that they know where they
come from.

thanks in advance,

Norbert

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

If you look, you'll notice there are no changes in the version in the
MagritteGlorp repository.  It's there because I use dependencies and often
put debugging code into Magritte while I'm testing, though I never commit it
like that.  What happens is that my local version gets marked as changed,
and then stamped with a version when committed.

The thing to do is simply merge in the code from the official Magritte
repository.  Get used to doing merges, that's how development is done in
Monticello.

Once you merge in the latest code, and test your own changes, you can commit
to the official repository so your changes can be reviewed.  If people like
your changes, they'll merge them into the main line.  With Magritte... the
main line is whatever line Lukas is working on.

Ramon Leon
http://onsmalltalk.com 

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> > I would like to put it on the official (lukas') repo. But I'm
> > not sure how to do it. Packages have information about the
> > package version they are based on. But the version numbers in
> > MagritteGlorp aren't present in the official repository. What
> > would be the result of putting my changed version on the
> > official repo?
> >

...
> If you look, you'll notice there are no changes in the version in the
> MagritteGlorp repository.  It's there because I use dependencies and often
> put debugging code into Magritte while I'm testing, though I never commit it
> like that.  What happens is that my local version gets marked as changed,
> and then stamped with a version when committed.
>
I can see in MagritteGlorp there are two Magritte-Model revisions.
Newest is rjl.236 which depends on rjl.235 which depends on rjl.234.
But rjl.234 isn't in this repository. So at first sight I don't
have a chance to see from which official version number the first
rjl version has been forked off. And both could be developed in
parallel for a longer time keeping the version number similar.

> The thing to do is simply merge in the code from the official Magritte
> repository.  Get used to doing merges, that's how development is done in
> Monticello.
>
Yes if you merge per default it doesn't really depend which version
history the packages have. They are just different. But I still think
any kind of track information could be helpful.

> Once you merge in the latest code, and test your own changes, you can commit
> to the official repository so your changes can be reviewed.  If people like
> your changes, they'll merge them into the main line.  With Magritte... the
> main line is whatever line Lukas is working on.
>

Ok, sounds reasonable. I put a fresh note on my todo list about this.
I 'll have a closer look at monotone (http://www.venge.net/monotone/ ).
I like the way the handle patches.  

Norbert

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

> I can see in MagritteGlorp there are two Magritte-Model revisions.
> Newest is rjl.236 which depends on rjl.235 which depends on rjl.234.
> But rjl.234 isn't in this repository. So at first sight I
> don't have a chance to see from which official version number
> the first rjl version has been forked off. And both could be
> developed in parallel for a longer time keeping the version
> number similar.

Those numbers are meaningless, ignore revision numbers.  Just diff the code,
you'll see there are no changes to Magritte.  I'll try and be more careful
about committing things that look like forks that aren't.

> Ok, sounds reasonable. I put a fresh note on my to-do list about this.
> I 'll have a closer look at monotone
> (http://www.venge.net/monotone/ ).
> I like the way the handle patches.  
>
> Norbert

That's a file based version control system, it's not going to work for
Smalltalk code.  Learn how Monticello works, it's is the main version
control system for Squeak, and I don't see that changing any time soon.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi all,
I'm new to Smalltalk and Squeak and I have a question.
I tried some examples from chapter Processes from "Smalltalk by Example"
book. I executed the following code several times but the output was
quite different as I suppose and differed from time to time.
Furthermore evaluation went a bit slowly.

[10 timesRepeat: [Transcript show: '2']] fork.
[10 timesRepeat: [Transcript show: '1']] fork.
Transcript cr.

2222222212121111111
2222222121212111111
22222222221111111111
2212121212121212121
2222222222111111111
2222222222111111111
2222121212121212111
22222222221111111111
22222222221111111111
2212121212121212121
...

In VisualWorks the same example works right. As described in the book.
I use Squeak 3.9 7067.

Is this a bug or i do something wrong?

Thanks,

George

P.S. Execuse me my poor english, please.
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi George,

I'm not sure what you expect to happen.  The code you are running basically
says go off on your own and do something.  A fork creates a different thread
that processes instructions on its own, but the two processes are not
coordinated the scheduler just gives them time when it can.  Notice though
that the Transcript cr. runs first which shows you that the two forked lines
above went off on their own.

VW may give the illusion that the processes are coordinated but they may
just have a better, more consistent scheduler.  Bottom line is you should
not count on threads to process in any coordinated way.

Does that help?

Ron Teitelbaum



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

George,

You'll find that writing to the Transcript always slows things down. I
assume it's the time for writing to the Transcript that also causes
the second process to start after a different interval each time.
Writing the results into an OrderedCollection will be much faster, and
more predictable:

a := OrderedCollection new.
[10 timesRepeat: [a addLast: '2'. (Delay forMilliseconds: 1) wait]] fork.
[10 timesRepeat: [a addLast: '1'. (Delay forMilliseconds: 1) wait]] fork.
a inspect.

consistently gives 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1.

Without the delay:

a := OrderedCollection new.
[10 timesRepeat: [a addLast: '2']] fork.
[10 timesRepeat: [a addLast: '1']] fork.
a inspect.

consistently gives 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1.

Cheers,
Michael
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Feb 20, 2007, at 11:05 , Michael Davies wrote:

> George,
>
> You'll find that writing to the Transcript always slows things down. I
> assume it's the time for writing to the Transcript that also causes
> the second process to start after a different interval each time.

Besides, it interferes with processes because it has a Mutex  
nowadays. Which is good, but it distorts what you would observe  
without the Transcript involved.

This is because waiting on Delay (or, rather on the Semaphore inside)  
causes the current process to block, and the next process on the same  
priority to run. The same could be achieved by "Processor yield"  
instead of waiting on the Delay. This is "cooperative". Or, you could  
have a higher-priority scheduler that time-slices the lower-priority  
ones by suspending them in turn, which does not need cooperation.

> Without the delay:
>
> a := OrderedCollection new.
> [10 timesRepeat: [a addLast: '2']] fork.
> [10 timesRepeat: [a addLast: '1']] fork.
> a inspect.
>
> consistently gives 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1.

These processes are too short-lived to ever get interrupted by a  
higher priority process. So the first one runs to completion, then  
the second one. Try this instead:

a := String new writeStream.
p1 := [[a nextPut: $1] repeat] forkAt: Processor userBackgroundPriority.
p2 := [[a nextPut: $2] repeat] forkAt: Processor userBackgroundPriority.
10 timesRepeat: [(Delay forMilliseconds: 1) wait].
p1 terminate.
p2 terminate.
a contents

This puts the two processes into a lower priority than the UI  
process. We then stop the UI process 10 times for one millisecond -  
this is our scheduler. Each time, the next lower-priority process is  
given time to run - that is the default scheduling behavior. The  
result are nicely alternating runs of ones and twos as you would  
expect: '111111111122222222222111111111111122222222222...'

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Thanks for this answer, Ron. But actually I'm not confused with order in
wich '1' and '2' presents in result line. I can't understand why in some
cases this code results ten '1' and ten '2' and in some cases it results
ten '2' and only nine '1'?
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Thanks, Michael!
Now I know, that it isn't a problem of BlockClosure's fork method, but a
specific behaviour of Transcript. Code you give in your message result
the same line as VW.

George
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

George,

Ohhhhh I'm really sorry.  It's funny now that I go back and look I'm
surprised that I missed that.  That's a horse of a different color.  

Basically to answer your question Transcript is not thread safe.  I'm not
sure exactly where it goes wrong but I suspect that it is probably doing a
copy somewhere and if one collection is used as a source and is copied at
the same time with two new additions then one gets lost.

To fix that you can set a semaphore which basically says don't try to access
Transcript from two places at exactly the same time.

semaphore := Monitor new.
[10 timesRepeat: [semaphore critical: [Transcript show: '2']]] fork.
[10 timesRepeat: [semaphore critical: [Transcript show: '1']]] fork.
Transcript cr.

This should make transcript thread safe.

Hope that helps,

Ron Teitelbaum




_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Feb 20, 2007, at 21:28 , George Herolyants wrote:

> Thanks for this answer, Ron. But actually I'm not confused with  
> order in wich '1' and '2' presents in result line. I can't  
> understand why in some cases this code results ten '1' and ten '2'  
> and in some cases it results ten '2' and only nine '1'?

Oh, that's indeed a bug. Transcript is unreliable when called from  
different processes. The mutex inside the Transcript only protects  
the change reporting but not the actual stream writing.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Ron, Michael and Bert, thank you very much for your help!

George
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On 20 févr. 07, at 21:55, Bert Freudenberg wrote:

Bert what do you mean by change reporting?

Stef
>
> - Bert -
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Feb 28, 2007, at 20:56 , stephane ducasse wrote:

It is only used in

        TranscriptStream>>endEntry

to protect

        self changed: #appendEntry.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners