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
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
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
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
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
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.
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
From: George Herolyants Sent: Monday, February 19, 2007 4:46 PM
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 Beginners@lists.squeakfoundation.org 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'?
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
-----Original Message----- From: beginners-bounces@lists.squeakfoundation.org [mailto:beginners- bounces@lists.squeakfoundation.org] On Behalf Of George Herolyants Sent: Tuesday, February 20, 2007 3:28 PM To: A friendly place to get answers to even the most basic questions aboutSqueak. Subject: Re: [Newbies] BlockClosure>>fork problem
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Ron, Michael and Bert, thank you very much for your help!
George
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 -
On 20 févr. 07, at 21:55, Bert Freudenberg wrote:
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 what do you mean by change reporting?
Stef
- Bert -
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On Feb 28, 2007, at 20:56 , stephane ducasse wrote:
On 20 févr. 07, at 21:55, Bert Freudenberg wrote:
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 what do you mean by change reporting?
It is only used in
TranscriptStream>>endEntry
to protect
self changed: #appendEntry.
- Bert -
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
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.
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.
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 -
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@lists.squeakfoundation.org
-
Bert Freudenberg -
George Herolyants -
Michael Davies -
Norbert Hartl -
Ramon Leon -
Ron Teitelbaum -
stephane ducasse