Updates:
Status: Closed
Comment #7 on issue 1328 by marcus.d...@gmail.com: Remove old input sensor
classes
http://code.google.com/p/pharo/issues/detail?id=1328
It seems the old classes are already removed
Updates:
Status: Closed
Comment #2 on issue 3741 by marcus.d...@gmail.com: Decompiler hangs
http://code.google.com/p/pharo/issues/detail?id=3741
Hello,
Can you check in the latest 1.3? I can not as there is not enough
information to re-create the bug.
Updates:
Status: Duplicate
Mergedinto: 1405
Comment #2 on issue 3005 by marcus.d...@gmail.com: Support for SCIM on Linux
http://code.google.com/p/pharo/issues/detail?id=3005
(No comment was entered for this change.)
Comment #5 on issue 1405 by marcus.d...@gmail.com: Ubuntu vm : inputting
return character on belgian keyboard layout is different in pharo than in
other programs
http://code.google.com/p/pharo/issues/detail?id=1405
Issue 3005 has been merged into this issue.
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
On Apr 3, 2011, at 9:35 AM, Marcus Denker wrote:
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
.. the all green image of today from Hudson. Yes, this is not repeatable and
tomorrow
the hudson one might be different. But we need to move on. 1.1 was build
Updates:
Labels: -Milestone-1.2 Milestone-1.2.2
Comment #4 on issue 3911 by marcus.d...@gmail.com: Change updater to allow
updating a release image
http://code.google.com/p/pharo/issues/detail?id=3911
(No comment was entered for this change.)
Excellent!
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
.. the all green image of today from Hudson. Yes, this is not repeatable and
tomorrow
the hudson one might be different. But we need to move on. 1.1 was build just
once, too.
Exactly.
So we can
Thanks Markus
Hil
Le 03/04/2011 09:35, Marcus Denker a écrit :
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
Marcus
--
Marcus Denker -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.
--
Education 0.2 --
Updates:
Labels: -Milestone-1.2 Milestone-1.2.2 Milestone-1.3
Comment #1 on issue 3912 by marcus.d...@gmail.com: Circular dependency with
GLMOrangeUITheme
http://code.google.com/p/pharo/issues/detail?id=3912
(No comment was entered for this change.)
Updates:
Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage
Milestone-1.3-DevImage
Comment #7 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra
horizontal scrollbar
http://code.google.com/p/pharo/issues/detail?id=3754
(No comment was entered for this change.)
Updates:
Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage
Comment #23 on issue 3706 by marcus.d...@gmail.com: In OB: Text in comment
pane of Browser uses syntax highlighting
http://code.google.com/p/pharo/issues/detail?id=3706
(No comment was entered for this change.)
Updates:
Labels: -Milestone-1.2-DevImage Milestone-1.2.2-DevImage
Comment #1 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load
latest code from OB Repository
http://code.google.com/p/pharo/issues/detail?id=3842
(No comment was entered for this change.)
On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote:
Excellent!
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
.. the all green image of today from Hudson. Yes, this is not repeatable and
tomorrow
the hudson one might be different. But we need to move on. 1.1
Comment #8 on issue 3754 by renggli: Omnibrowser's an extra horizontal
scrollbar
http://code.google.com/p/pharo/issues/detail?id=3754
FYI: I cannot reproduce this problem in Pharo 1.2
A pity that broken OB code is used, nevertheless it is quite usable.
Lukas
On 3 April 2011 09:58, Marcus Denker marcus.den...@inria.fr wrote:
On Apr 3, 2011, at 9:41 AM, Tudor Girba wrote:
Excellent!
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
.. the all
On Apr 3, 2011, at 10:22 AM, Lukas Renggli wrote:
A pity that broken OB code is used, nevertheless it is quite usable.
Yes, and I added a bug report on March 22:
http://code.google.com/p/pharo/issues/detail?id=3842
But nobody cared to react. So how important can it be?
There are
On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote:
On 02.04.2011 09:16, Stéphane Ducasse wrote:
Henrik what is your answer to problem 1
Problem 1
- the second announcement was never sent, because the first one broke
the second was blocked.
we should make sure that if
Comment #1 on issue 3709 by renggli: Clean OB**WithShout in omnibrowser
http://code.google.com/p/pharo/issues/detail?id=3709
This is pretty much cleaned up in
http://source.lukas-renggli.ch/omnibrowser/ and
http://source.lukas-renggli.ch/unsorted/.
PPS. There's a neat method called #on:send:to:, which would be perfect for
the different actions in RPackage-SystemIntegration.
I'm trying to understand how this on:send:to: would help us.
Because
Nautilus registered to system announcer
Now I do not understand why RPackageOrganizer
tx hilaire
keep pushing.
stef
On Apr 2, 2011, at 8:55 PM, Hilaire Fernandes wrote:
Dr. Geo (http://www.ofset.org/drgeo) is becoming better release after
release. It is proposed for all three major systems and the XO OLPC
laptop for kid.
It has been downloaded several thousand of times, it
On Apr 2, 2011, at 9:10 PM, Toon Verwaest wrote:
Hi all,
as you know I'm working on stateful traits using my new classbuilder
no
Are you?
etc... Now I noticed that methods are highlighted always inside of the
context of the class that's active in the class browser. How can I change
tx!
and yes we should continue
On Apr 3, 2011, at 9:36 AM, Marcus Denker wrote:
On Apr 3, 2011, at 9:35 AM, Marcus Denker wrote:
https://gforge.inria.fr/frs/download.php/28435/Pharo-1.2.1-11.04.03.zip
.. the all green image of today from Hudson. Yes, this is not repeatable
Comment #3 on issue 3786 by jvdsa...@gmail.com: Debug test .. (d) menu
option in OBSystenBrowser gives SystemGuardException in Pharo 1.2
http://code.google.com/p/pharo/issues/detail?id=3786
This bug is still present in the 1.2.1 development image.
Updates:
Status: Duplicate
Mergedinto: 3842
Comment #2 on issue 3709 by marcus.d...@gmail.com: Clean OB**WithShout in
omnibrowser
http://code.google.com/p/pharo/issues/detail?id=3709
So this will be fixed with a merge
Comment #2 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load
latest code from OB Repository
http://code.google.com/p/pharo/issues/detail?id=3842
Issue 3709 has been merged into this issue.
Comment #3 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load
latest code from OB Repository
http://code.google.com/p/pharo/issues/detail?id=3842
Issue 3786 has been merged into this issue.
Updates:
Status: Duplicate
Mergedinto: 3842
Comment #4 on issue 3786 by marcus.d...@gmail.com: Debug test .. (d) menu
option in OBSystenBrowser gives SystemGuardException in Pharo 1.2
http://code.google.com/p/pharo/issues/detail?id=3786
So then this code is in the other
Updates:
Status: Closed
Comment #9 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra
horizontal scrollbar
http://code.google.com/p/pharo/issues/detail?id=3754
(No comment was entered for this change.)
Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3943 by marcus.d...@gmail.com: remove ExternalSettings from MC
http://code.google.com/p/pharo/issues/detail?id=3943
ExternalSettings... this changeset removes ExternalSettings from it's last
client.
In the
Status: Accepted
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3944 by marcus.d...@gmail.com: ClassHierarchyTest needs to be
moved to KernelTests package
http://code.google.com/p/pharo/issues/detail?id=3944
ClassHierarchyTest needs to be moved to KernelTests package
Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3945 by marcus.d...@gmail.com: Remove squeakland plugin methods
from SystemVersion
http://code.google.com/p/pharo/issues/detail?id=3945
Remove squeakland plugin methods from SystemVersion
Attachments:
Oh yes.. I am :)
http://pinocchio.unibe.ch/~tverwaes/slots.tar.gz gives you an image with
an example of a stateful trait open. The state is always private to the
class / trait at the moment and it already seems to work pretty well. I
modified the NewInspector slightly to show you the proper
Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3946 by marcus.d...@gmail.com: remove some more uniclasses/player
related code
http://code.google.com/p/pharo/issues/detail?id=3946
remove some more uniclasses/player related dead code
Attachments:
Status: FixProposed
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3947 by marcus.d...@gmail.com: remove #floodFill:
http://code.google.com/p/pharo/issues/detail?id=3947
Form removeSelector: #floodFill:at:!
Form removeSelector: #floodFill:at:tolerance:!
... references
Updates:
Status: FixProposed
Comment #1 on issue 3944 by marcus.d...@gmail.com: ClassHierarchyTest needs
to be moved to KernelTests package
http://code.google.com/p/pharo/issues/detail?id=3944
fix attached
Attachments:
ClassHierarchyTest.1.cs 242 bytes
Updates:
Status: FixProposed
Comment #1 on issue 3942 by marcus.d...@gmail.com: Transcript missing
compatibility method ensureCr
http://code.google.com/p/pharo/issues/detail?id=3942
fix attached
Attachments:
EnsureCr.1.cs 360 bytes
Status: Accepted
Owner: marcus.d...@gmail.com
Labels: Milestone-1.3
New issue 3948 by marcus.d...@gmail.com: Transcript and ThreadedTranscript
needs to be merged
http://code.google.com/p/pharo/issues/detail?id=3948
Transcript is now not a Stream subclass anymore.
ThreadedTranscript's
Oh yes.. I am :)
cool
How are you dealing with the fact that the application of trait with state may
change the layout of the class user and that you should recompile
all the class method to deal with that. And if you have two traits having state
you should do the same but for the traits
Hi,
The Moose build uses 1.2.1 now:
http://hudson.moosetechnology.org/job/moose-latest-dev/
Cheers,
Doru
On 3 Apr 2011, at 10:45, Stéphane Ducasse wrote:
tx!
and yes we should continue
On Apr 3, 2011, at 9:36 AM, Marcus Denker wrote:
On Apr 3, 2011, at 9:35 AM, Marcus Denker wrote:
How are you dealing with the fact that the application of trait with state may
change the layout of the class user and that you should recompile
all the class method to deal with that. And if you have two traits having state
you should do the same but for the traits themselves.
So this means
Hi,
I think that this dialogue goes in too many directions, so I will try to
provide a summary. Maybe this helps.
As I understand, Stef has the following problem:
- there is one announcer with two listeners
- the problem is that if the first listener raises an error, the second
listener is not
Status: FixProposed
Owner: renggli
Labels: Milestone-1.1.2
New issue 3949 by renggli: Coverage for Cog
http://code.google.com/p/pharo/issues/detail?id=3949
The fix below makes sure that the coverage method is properly flushed from
the method cache. It doesn't seem to yet fix all problems of
Then the classbuilder will build classes by always following the
public path. Sidescopes aren't public. When you compile methods on the
trait, its scopes are public; but when they are installed, they aren't
public since they are sidescopes.
I obviously meant, the compiler will compile methods
So now I could apply syntax coloring in the context of the trait rather than
the class.
Do you mean coloring message sends in a trait's method? For self call that is
not specified in the requirement?
Since in my implementation state is all private to the trait / class, they
should be able
On Apr 3, 2011, at 12:30 PM, Tudor Girba wrote:
Hi,
I think that this dialogue goes in too many directions, so I will try to
provide a summary. Maybe this helps.
As I understand, Stef has the following problem:
- there is one announcer with two listeners
- the problem is that if the
Do you mean coloring message sends in a trait's method? For self call that is
not specified in the requirement?
I meant that if you look at a method coming from a trait inside of the
class browser; while your browser is pointing at a class. Instance
variables were colored red since they
I tried the image. I hadn't seen such a look for years :-)
StatefulTrait named: #TStatefulTest
layout: PointerLayout
slots: {
#tfirst = Slot.
#tsecond = Slot.
}
uses: {}
category: #'Slot-Traits-Test'
I checked what layout:
I just finished building a new image based on the helvetia image.
http://pinocchio.unibe.ch/~tverwaes/PlayOut.tar.gz
The previous image is what I've been developing in, and yes, it's pretty
annoying... I hope that the new image will perform better. But since I
already noticed that the new
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
http://bergel.eu/download/papers/Berg07e-StatefulTraits.pdf)
We have T.y
Can you merge state? What happens with C.x uses T.x ? Methods of T will use
T.x and methods of C will use C.x?
At the moment you can't, but in our slot library we have alias slots. So that
we could use to do the same tricks as with methods: required slots, provided
slots, defrosted
On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
On 04/03/2011 02:31 PM, Alexandre Bergel wrote:
Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x
and methods of C will use C.x?
At the moment you can't, but in our slot library we have alias slots. So that we could
use to do the same tricks as with methods:
Yes I see, I did forget to implement all the tools to make it work. You
know... I started the stateful traits implementation on Friday... I'm glad
that I'm as far as I am ;) However, in the new image I can close it.
Exceptions are just very slow for some reason.
This is cool that you're
On 04/03/2011 02:31 PM, Alexandre Bergel wrote:
Can you merge state? What happens with C.x uses T.x ? Methods of T will use T.x
and methods of C will use C.x?
At the moment you can't, but in our slot library we have alias slots. So that we could
use to do the same tricks as with methods:
Indeed. And this is not different from changing a layout of a class having as
impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway
whenever it installs the trait. What I do is, I just let the trait compile
itself on the subpart
On Apr 3, 2011, at 1:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
Yes, and the
On 04/03/2011 02:37 PM, Alexandre Bergel wrote:
Indeed. And this is not different from changing a layout of a class having as
impact that you have to update the methods.
The default traits implementation already recompiles all methods anyway
whenever it installs the trait. What I do is, I just
On 04/03/2011 02:29 PM, Alexandre Bergel wrote:
I guess that what Stef meant is the following:
One of the problems when sharing code among mixin and stateful-trait
application is that the physical layout of instances varies between mixin
applications. (Section 6.5 of
Updates:
Status: Closed
Comment #5 on issue 3911 by marcus.d...@gmail.com: Change updater to allow
updating a release image
http://code.google.com/p/pharo/issues/detail?id=3911
in 12346
Updates:
Labels: -Milestone-1.1.2 Milestone-1.2.2 Milestone-1.3
Comment #1 on issue 3949 by marcus.d...@gmail.com: Coverage for Cog
http://code.google.com/p/pharo/issues/detail?id=3949
in 1.2.2a
TODO: 1.3
Updates:
Labels: -Milestone-1.2.2
Comment #2 on issue 3912 by marcus.d...@gmail.com: Circular dependency with
GLMOrangeUITheme
http://code.google.com/p/pharo/issues/detail?id=3912
This is the same in 1.3
I propose, as this is a purely cosmetic problem, to postpone this to 1.3
and
Comment #10 on issue 3754 by thereluc...@fastmail.fm: Omnibrowser's an
extra horizontal scrollbar
http://code.google.com/p/pharo/issues/detail?id=3754
I just tried it with:
'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.52] 21.0‘ and with
'Squeak4.1 of 17 April 2010 [latest update:
On Sat, Apr 2, 2011 at 10:38 AM, laurent laffont
laurent.laff...@gmail.comwrote:
On Sat, Apr 2, 2011 at 10:14 AM, Marcus Denker marcus.den...@inria.frwrote:
On Apr 2, 2011, at 9:55 AM, laurent laffont wrote:
Patrick,
I think we should have a ConfigurationOfPharoThemes with all the themes
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
- the initialization is not modular so you end up write a lot
Updates:
Status: Started
Comment #11 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra
horizontal scrollbar
http://code.google.com/p/pharo/issues/detail?id=3754
(No comment was entered for this change.)
As with 1.2 in general, I gave up on auto build... as we will move to the VMs
we build ourselfes in 1.3,
the idea is to keep 1.2 as simple as possible.
- I added the windows vm that Torsten send me
- I did not update the mac or unix vm from 1.1.1...
Updates:
Status: Closed
Comment #5 on issue 3645 by marcus.d...@gmail.com: Update Hudson One-Click
build files for 1.2
http://code.google.com/p/pharo/issues/detail?id=3645
I did a 1.2 oneclick.
We will use our own builds for 1.3 soon, for 1.2 we don't bother to
configure hudson as
On 04/03/2011 04:58 PM, Stéphane Ducasse wrote:
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
I'm not sure if it
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
At least, Toon will avoid all the problems we had with the renaming and
On 04/03/2011 06:46 PM, Alexandre Bergel wrote:
Thanks I should digest it.
Now what I did not like in our stateful model was that
- in introduced too many operators
- I'm not sure I like trait state to be private because it changes a
lot the smalltalk model
At least, Toon will
Out of the box, system browsers are opening with a scroll bar between the lists
and code pane. Click on it, and the bar disappears.
Curious which vm was in use, I tried:
SmalltalkImage current vmVersion 'Squeak3.10.2 of ''5 June 2008'' [latest
update: #7179]'
Looks weird?? Ask the vm
The thing is that all things, even the smallest tiniest triviality, happens if
someone *does* it. Nothing happens by itself.
I'm probably very naive here; and also a bit lazy and so on... So: could
you point me at a short text that describes exactly what I have to do to
get any line of code
On Sun, Apr 3, 2011 at 6:31 PM, Toon Verwaest toon.verwa...@gmail.comwrote:
The thing is that all things, even the smallest tiniest triviality,
happens if someone *does* it. Nothing happens by itself.
I'm probably very naive here; and also a bit lazy and so on... So: could
you point me at
On Apr 3, 2011, at 5:31 PM, Marcus Denker wrote:
As with 1.2 in general, I gave up on auto build... as we will move to the VMs
we build ourselfes in 1.3,
the idea is to keep 1.2 as simple as possible.
- I added the windows vm that Torsten send me
- I did not update the mac
Hi,
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't
seen 1.2.0, no big party, no 1 million download contest, BBC announcement...
:) I wonder how we can improve the process for 1.3.
I'm thinking about:
- not starting Pharo 1.4 too soon as I feel it will steal energy from
On Apr 3, 2011, at 7:13 PM, laurent laffont wrote:
Hi,
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't
seen 1.2.0, no big party, no 1 million download contest, BBC announcement...
:) I wonder how we can improve the process for 1.3.
Yes, that is why I did not
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs. Full
release does not work.
1) We don't develop the system using the tools that we tell people to use.
- bugs don't get fixed
- there is no pressure on improving the tools
On Sun, Apr 3, 2011 at 7:18 PM, Marcus Denker marcus.den...@inria.frwrote:
On Apr 3, 2011, at 7:13 PM, laurent laffont wrote:
Hi,
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't
seen 1.2.0, no big party, no 1 million download contest, BBC announcement...
:) I
Rather than abandon core vs full, here's a thought on a slightly different
approach...
Do development in the FULL version. That way the tools are used and bugs in the
tools are fixed as the changes are made in the CORE...you are keeping the FULL
alive, not adding new features, etc, since that
On Apr 3, 2011, at 7:12 PM, laurent laffont wrote:
Hi,
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't
seen 1.2.0, no big party, no 1 million download contest, BBC announcement...
:) I wonder how we can improve the process for 1.3.
I'm thinking about:
- not
as I'm a little lost on Pharo 1.2 (1.2.1 full was announced but I haven't
seen 1.2.0, no big party, no 1 million download contest, BBC announcement...
:) I wonder how we can improve the process for 1.3.
Yes, that is why I did not want to decouple the release of Core from Full.
- Get rid of the Core/Full image destinction. This does not work. And I will
not do a release with having two images again... it never worked, and it will
never work.
Yes but for that we need a good browser that we can maintain.
Yes, 2 images seems hard to maintain and hard to
On Apr 3, 2011, at 7:31 PM, Marcus Denker wrote:
Hi,
So finally I have to admit that I am defeated: The way we do the Core vs.
Full release does not work.
1) We don't develop the system using the tools that we tell people to use.
- bugs don't get fixed
-
I really agree with you Marcus. It sounds to me that core/dev is a
black and white approach.
I know there are no resources, but what do you think of starting with
a minimum image and the build over more sophisticated images?
-Kernel image
-Core image
-Image with really basic browsing/scm tools
Norbert,
Today I have found that I can get GemTools to work on the mac using Squeak
4.2.4beta1U.
Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a
Space is low error, because the size comes back as 1330942246849085449, instead
of a reasonable number).
The image is
On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote:
Norbert,
Today I have found that I can get GemTools to work on the mac using Squeak
4.2.4beta1U.
Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a
Space is low error, because the size comes back as
On Apr 3, 2011, at 12:48 PM, Dale Henrichs wrote:
On Apr 3, 2011, at 12:36 PM, Dale Henrichs wrote:
Norbert,
Today I have found that I can get GemTools to work on the mac using Squeak
4.2.4beta1U.
Squeak 4.2.5beta1U fails when an FFI call returns an incorrect value (get a
Space
On 03.04.2011 10:35, Stéphane Ducasse wrote:
On Apr 2, 2011, at 5:14 PM, Henrik Sperre Johansen wrote:
On 02.04.2011 09:16, Stéphane Ducasse wrote:
Henrik what is your answer to problem 1
Problem 1
- the second announcement was never sent, because the first one broke
the second was
On Apr 3, 2011, at 9:34 PM, Hernán Morales Durand wrote:
I really agree with you Marcus. It sounds to me that core/dev is a
black and white approach.
I know there are no resources, but what do you think of starting with
a minimum image and the build over more sophisticated images?
Updates:
Status: Closed
Comment #2 on issue 3949 by stephane...@gmail.com: Coverage for Cog
http://code.google.com/p/pharo/issues/detail?id=3949
Tx lukas
in 12131
Updates:
Status: Closed
Comment #1 on issue 3947 by stephane...@gmail.com: remove #floodFill:
http://code.google.com/p/pharo/issues/detail?id=3947
in 13131
Comment #1 on issue 3946 by stephane...@gmail.com: remove some more
uniclasses/player related code
http://code.google.com/p/pharo/issues/detail?id=3946
Argh! Terrible design add yours to the list no comment.
Comment #2 on issue 3946 by stephane...@gmail.com: remove some more
uniclasses/player related code
http://code.google.com/p/pharo/issues/detail?id=3946
in 13131
Updates:
Status: closed
Comment #3 on issue 3946 by stephane...@gmail.com: remove some more
uniclasses/player related code
http://code.google.com/p/pharo/issues/detail?id=3946
(No comment was entered for this change.)
Updates:
Status: Closed
Comment #1 on issue 3945 by stephane...@gmail.com: Remove squeakland
plugin methods from SystemVersion
http://code.google.com/p/pharo/issues/detail?id=3945
in 13131
Updates:
Status: Closed
Comment #2 on issue 3944 by stephane...@gmail.com: ClassHierarchyTest needs
to be moved to KernelTests package
http://code.google.com/p/pharo/issues/detail?id=3944
in 13131
13131
-
- Issue 3949: Coverage for Cog. Thanks Lukas Renggli.
- Issue 3947: remove #floodFill:. Thanks Marcus Denker.
- Issue 3946: remove some more uniclasses/player related code. Thanks Marcus
Denker.
- Issue 3945: Remove squeakland plugin methods from SystemVersion. Thanks
Marcus
Comment #2 on issue 3877 by stephane...@gmail.com: Check reduced complexity
for UI themes
http://code.google.com/p/pharo/issues/detail?id=3877
first step in that direction done: repackaged theme, rename Glamour ones,
removed soft squeak
Updates:
Status: Closed
Comment #3 on issue 3912 by stephane...@gmail.com: Circular dependency with
GLMOrangeUITheme
http://code.google.com/p/pharo/issues/detail?id=3912
So far I move all the themes into Polymorph. Removed SoftSqueak, started to
rename Glamour (should rename the
1 - 100 of 101 matches
Mail list logo
