really really nice.
Stef
On Jun 29, 2012, at 4:21 PM, Hilaire Fernandes wrote:
Marin asks me if Dr. Geo can do it:
http://www.ericforman.com/blog/anthony-mccall-solid-light/
No problem:
http://www.dailymotion.com/video/xrupz0_1310-programmed-sketch-rulers_tech
--
Dr. Geo --
Indeed. DrGeo is not multithread safe.
In this example, the animation is done in a background thread, at the
end of the smalltalk code this is the canvas do: [] loop code.
So when playing interactively with the sketch, changing parameters for
example, your are forcing a sketch update, and at
Indeed. DrGeo is not multithread safe.
In this example, the animation is done in a background thread, at the
end of the smalltalk code this is the canvas do: [] loop code.
So when playing interactively with the sketch, changing parameters for
example, your are forcing a sketch update,
Marin asks me if Dr. Geo can do it:
http://www.ericforman.com/blog/anthony-mccall-solid-light/
No problem:
http://www.dailymotion.com/video/xrupz0_1310-programmed-sketch-rulers_tech
--
Dr. Geo -- http://www.drgeo.eu
Nice.
Some edge case artifacts are visible though...
Nicolas
2012/6/29 Hilaire Fernandes hilaire.fernan...@edu.ge.ch:
Marin asks me if Dr. Geo can do it:
http://www.ericforman.com/blog/anthony-mccall-solid-light/
No problem:
http://blog.ofset.org/hilaire/index.php?post/2011/11/18/3D-Cube-section
Hilaire
http://blog.ofset.org/hilaire/index.php?post/2011/10/28/Huge-sketch
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] on behalf of Hilaire Fernandes
[hilaire.fernan...@edu.ge.ch]
Sent: Sunday, November 06, 2011 4:18 AM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project
Le 06/11/2011 15:42, Schwab,Wilhelm K a écrit :
Small typo: look at the status bar of the second image. It reads
Erase and object... - should be an. The second and is of
course correct.
Thanks, I fixed it indeed
Dumb question: what is it that makes the file so big? At first
glance, it
rofl: So, if you're thinking: 'Oh my gosh! I hate Smalltalk!' and 'This is
just one more thing for me to learn' and 'I don't know how to do this!' and 'It
just feels painful!' and 'Uh, maybe I'll just go and have a route canal*...'.
* route canal is something painful a dentist does to you...
On Mar 24, 2010, at 10:50 PM, Lukas Renggli wrote:
So this is probably a glitch somewhere
I doubt so.
Lukas: I ***KNOW*** how MC branching/merging works. I KNOW IT. Now I'm
trying to understand how the moved package
could be moved in treated while it should have been to pharo.
I
this is strange before lunch I could select Polymorph-Widgets and merge at will
and now
I cannot anymore because I got a message could not find versions for example 107
Now this is really strange because this is the first version that was merged so
normally it should be found.
It is either in
this is strange before lunch I could select Polymorph-Widgets and merge at
will and now
I cannot anymore because I got a message could not find versions for example
107
This problem is to be expected when you move or delete versions.
You see this message when the closest ancestor of the
what is strange is that when I merge the latest loaded version I got the normal
no changes
and I could merge without having to add a new repository.
I think that in squeak they cut the problem (if you do not have the history
what do you do).
You should still be able to merge.
Setf
On Mar 24,
what is strange is that when I merge the latest loaded version I got the
normal no changes
and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you
load (so it can always be found). And the delta between the working
copy
On Mar 24, 2010, at 6:46 PM, Lukas Renggli wrote:
what is strange is that when I merge the latest loaded version I got the
normal no changes
and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you
load (so it can
what is strange is that when I merge the latest loaded version I got the
normal no changes
and I could merge without having to add a new repository.
Sure, because in this situation the common ancestor is the version you
load (so it can always be found). And the delta between the working
Stef and Lukas,
The other situation that I have seen these types of errors is when the package
that I am merging into(?) does not have the repository where the common
ancestor mcz file is located.
For example if I have Seaside.gemstone-dkh.500 with
http://seaside.gemstone.com/ss/seaside in
The ancestry cannot be lost. The .mcz files are the one thing that can
disappear.
Yes I know but the result is the same.
The working copy is just one of the variable things in the merge.
There is also the other version you load (and that might be different
in your scenarios), and the
This is normal because ancestry cross over repository.
I think that there is something really strange. EIther you get a truly
distributed system or you get a local.
With MC you get a distributed which can be brittle (even if I understand well
the problem ancestry is solving).
I think that a
The ancestry is not broken! The problem is that you miss *ancestor
versions*, because they were deleted or moved.
I know now since we systematically merge during our process I wonder how we
break it.
May be this is when you publish the smalltalk rewrite. Could check if you have
I know now let me repeat the bug I see
This is not a bug of Monticello.
It is or may be of the network because
tell me the difference between scenario 1 and scenario 2?
I think that you do not read what I'm writing. There is no difference except
that in the first scenario it barks and the
So this is probably a glitch somewhere
I doubt so.
Lukas: I ***KNOW*** how MC branching/merging works. I KNOW IT. Now I'm trying
to understand how the moved package
could be moved in treated while it should have been to pharo.
I imagine that when you browsed the different repositories you
hi guy
with alain we encountered the following
A
B subclass of A
has order
now
order is moved to A
A
order
B
I thought that MC was loading leaves first.
Is it the case?
Stef
___
Pharo-project mailing list
24 matches
Mail list logo
