21 Dec
2006
21 Dec
'06
8:32 p.m.
May I suggest
that you remove #asString from UndefinedObject and
replace all #asString
sends by #displayString in Magritte. Once you have an inventory of
all these replacements,
you will just need to apply them to the Squeak package and do
another port. I found about
15 occurences of #asString sends in Magritte. Of course this would
have to be
negotiated with Lukas. That's why I copied him.
I seem to be haunted by #asString in every Smalltalk dialect I come
across. In my real life (a VisualAge/GemStone/ObjectStudio shop),
we've adopted #displayString as well. While I'm willing to make
that change, I'd certainly prefer it if we could prevail upon Lukas
to do it, if only to avoid coordination issues. 2) Among
others, the Seaside-VW bundle includes bundle Squeak.
This bundle is intended
to group all extensions that are needed by VisualWorks to look
like Squeak. It is used by
Seaside but can be used by any project that is ported from Squeak.
I could see that your
Magritte port contains a lot of extensions that would be better
placed in the Squeak bundle.
May I propose the following. I can create a version of the Squeak
and Seaside bundles in
the public store with as many as poissible of the Squeak
extensions needed by Magritte.
When it is ready, I let you know, then you will be able to remove
the extensions from your
Magritte port.
I'm quite happy to go this route. I was getting a little dismayed
at the number of Squeak-isms that I had to implement for the port,
and any work done getting them out of the Magritte package will
help other porting efforts. A question for Lukas: I came across the use of
SystemChangeNotifier in Magritte. I ended up either removing or no-
oping operations related to it. Is there something I'm losing as a
result? I couldn't find any uses outside of Magritte that didn't
appear to be related to the development environment itself.
There are two uses of SystemChangeNotifier, they should be probably
moved to the MACompatiblity class.
1. MAAutoSelectorAccessorTest: this one is only needed to prevent
from marking the test-package dirty as this tests adds/removes i-vars/
accessors.
2. MADescriptionBuilder: this one makes sure that the description
cache is flushed whenever a description method is changed/added/removed.
The first one isn't critical, as this is only a tweak to make the
test run clean. The second one is more critical, without it you need
to flush the description cache manually by executing
MADescriptionBuilder default flush
There were some concerns in the beginning that rebuilding those
descriptions over and over again is very costly, therefor I added the
caching. I don't know if this is still relevant. Probably it hurts
more than it helps, but we have to check.
Lukas, I've uncovered a small bug in
MAReportComponent. While the
#renderContentOn: method calls #labelId, that method is not
implemented in the class hierarchy. I'm not sure if the
implementation from MAElementComponent should be moved up, or if
something else was intended for the report hierarchy. For
reference, this is in package Magritte-Seaside-pmm.206.
I think this change was introduced by the latest change of Philippe,
maybe he can have a look?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
21 Dec
21 Dec
11:05 p.m.
New subject: [Seaside] Magritte for VisualWorks
On 2006-12-21, at 14:32, Lukas Renggli wrote:
The problem here is that this will turn the
Magritte-Core package
dependent on the Seaside package, because it already defines
#displayString. Otherwise I don't see a problem to adopt this in
the Squeak Code.
I guess the question that would need answering is, how many users
would be affected by having load the Seaside package first? In the
case of the VW port, I pre-req Seaside anyway. What how many Squeak
users are _not_ using Seaside with Magritte? I think both of those
users could live with having to load the Seaside code as well. :{)
There are two uses of SystemChangeNotifier, they
should be probably
moved to the MACompatiblity class.
Ah, yes, the "Incompatibility" class, as I call it. :{) That, and
the MADistribution class came over to VW with just about nothing
working. I got the test for #referenceStream: working, but only by
changing the test code. I have my doubts as to whether the block-
related stuff will really work properly as well, but I don't think
it's a big concern for the Seaside-based users that will be the
biggest (only) consumers in VW.
1. MAAutoSelectorAccessorTest: this one is only needed
to prevent
from marking the test-package dirty as this tests adds/removes i-
vars/accessors.
I don't believe this is an issue in VW/StORE - it would be in an ENVY
environment. I modified the code to just pass the message send on to
super.
There were some concerns in the beginning that
rebuilding those
descriptions over and over again is very costly, therefor I added
the caching. I don't know if this is still relevant. Probably it
hurts more than it helps, but we have to check.
Uh oh, the evil spectre of premature optimization rears its ugly head!
For development purposes, I can live with manually flushing the cache
as needed. For a runtime environment, my personal preference is to
use packaged images anyway, so I find it hard to worry too much about
the impact of code changes. If we document a need to flush the
cache, I think that should be sufficient, unless someone more into
the internals of VW browsers has a better idea.
I think this change was introduced by the latest
change of
Philippe, maybe he can have a look?
I'll do another port once we've figured out this one - I've found a
few other little things I'd like to clean up anyway.
--
============================================================
Thomas Koschate
--
============================================================
Thomas Koschate +1 416.716.5949
koschate(a)omasko.com FAX: +1 905.451.9268
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4659702E
22 Dec
22 Dec
9:35 a.m.
New subject: [Seaside] Magritte for VisualWorks
The problem
here is that this will turn the Magritte-Core package
dependent on the Seaside package, because it already defines
#displayString. Otherwise I don't see a problem to adopt this in
the Squeak Code.
I guess the question that would need answering is, how many users
would be affected by having load the Seaside package first? In the
case of the VW port, I pre-req Seaside anyway. What how many
Squeak users are _not_ using Seaside with Magritte? I think both
of those users could live with having to load the Seaside code as
well. :{) There are two
uses of SystemChangeNotifier, they should be
probably moved to the MACompatiblity class.
Ah, yes, the "Incompatibility" class, as I call it. :{) That, and
the MADistribution class came over to VW with just about nothing
working. There were
some concerns in the beginning that rebuilding those
descriptions over and over again is very costly, therefor I added
the caching. I don't know if this is still relevant. Probably it
hurts more than it helps, but we have to check.
Uh oh, the evil spectre of premature optimization rears its ugly head! For development purposes, I can live with manually
flushing the
cache as needed.
It was like this in beginning of Magritte. It is just more convenient
not to have to worry about invalid caches. Maybe in you case you want
to disable it altogether, have a look at MANamedBuilder and replace
its references (should be only one) with your own implementation that
does not cache.
For a runtime environment, my personal preference is
to use
packaged images anyway, so I find it hard to worry too much about
the impact of code changes. If we document a need to flush the
cache, I think that should be sufficient, unless someone more into
the internals of VW browsers has a better idea.
Yeah, for deployment this doesn't matter anymore. Descriptions you
bild programmatically (or you end-users are building) are not cached
anymore.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:24 a.m.
New subject: [Seaside] Magritte for VisualWorks
On 22 Dec 2006, at 09:35 , Lukas Renggli wrote:
I am using Magritte without Seaside, but you are right mostly
Magritte is used together with Seaside :-p
If #displayString was added (duplicated) to Magritte, wouldn't that
make Magritte independent of Seaside ?
Michel
The problem here is that this will turn the
Magritte-Core package
dependent on the Seaside package, because it already defines
#displayString. Otherwise I don't see a problem to adopt this in
the Squeak Code.
I guess the question that would need answering is, how many users
would be affected by having load the Seaside package first? In
the case of the VW port, I pre-req Seaside anyway. What how many
Squeak users are _not_ using Seaside with Magritte? I think both
of those users could live with having to load the Seaside code as
well. :{)
10:35 a.m.
New subject: [Seaside] Magritte for VisualWorks
The problem
here is that this will turn the Magritte-Core
package dependent on the Seaside package, because it already
defines #displayString. Otherwise I don't see a problem to adopt
this in the Squeak Code.
I guess the question that would need answering is, how many users
would be affected by having load the Seaside package first? In
the case of the VW port, I pre-req Seaside anyway. What how many
Squeak users are _not_ using Seaside with Magritte? I think both
of those users could live with having to load the Seaside code as
well. :{)
4:26 p.m.
New subject: [Seaside] Magritte for VisualWorks
On 22 Dec 2006, at 10:35 , Lukas Renggli wrote:
If #displayString was added (duplicated) to Magritte, wouldn't
that make Magritte independent of Seaside ?
Yes, but unfortunately Monticello 1 (as opposed to Monticello 2)
does not allow a method to be in two different packages. At least
as far as I know.
Should we give up trying ?
I already did that with different versions of the same method in
Seaside and SeasideAsync.
It just required extra care, making sure that SeasideAsync was not
loaded when publishing Seaside.
Michel.
> The
problem here is that this will turn the Magritte-Core
> package dependent on the Seaside package, because it already
> defines #displayString. Otherwise I don't see a problem to
> adopt this in the Squeak Code.
I guess the question that would need answering is, how many
users would be affected by having load the Seaside package
first? In the case of the VW port, I pre-req Seaside anyway.
What how many Squeak users are _not_ using Seaside with
Magritte? I think both of those users could live with having to
load the Seaside code as well. :{)
I am using Magritte without Seaside, but you are right mostly
Magritte is used together with Seaside :-p
10:54 p.m.
New subject: [Seaside] Magritte for VisualWorks
On 2006-12-22, at 03:35, Lukas Renggli wrote:
I was poking around the VW image today, and I've found a spot to hook
in flushing behavior fairly simply, if it's sufficient to flush just
the instance returned by MADescriptionBuilder class>>default.
Otherwise, I think a slightly more ambitious bit of coding will be
needed.
Otherwise, SeasidePlatformSupport looks like the place to add in some
hooks to register for change notification, since it already gets sent
#refactoringChange: when code is modified. What do you think, Michel?
--
============================================================
Thomas Koschate
For
development purposes, I can live with manually flushing the
cache as needed.
It was like this in beginning of Magritte. It is just more
convenient not to have to worry about invalid caches. Maybe in you
case you want to disable it altogether, have a look at
MANamedBuilder and replace its references (should be only one) with
your own implementation that does not cache.
23 Dec
23 Dec
9:12 a.m.
New subject: [Seaside] Magritte for VisualWorks
For development purposes, I can live with manually
flushing the
cache as needed.
It was like this in beginning of Magritte. It is just more
convenient not to have to worry about invalid caches. Maybe in you
case you want to disable it altogether, have a look at
MANamedBuilder and replace its references (should be only one)
with your own implementation that does not cache. Otherwise, SeasidePlatformSupport looks like the place
to add in
some hooks to register for change notification, since it already
gets sent #refactoringChange: when code is modified. What do you
think, Michel?
That's why there is MACompatiblity. All things in there that are
certainly not compatible with other dialects than Squeak, but
obviously the change-notification stuff is missing.
I cannot support starting to weaken the boundaries of packages. Just
have a look at Seaside, we are trying to clean it up a little in 2.7
now.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6603
days inactive
6605
days old
7 comments
3 participants
participants (3)
-
Lukas Renggli -
Michel Bany -
Thomas Koschate