[Patch] Both source files now with 512MB capacity Klaus D. Witzel

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Patch] Both source files now with 512MB capacity Klaus D. Witzel

Jerome Peace
Hi Klaus,

Thank you for removing a limitation from squeak.

I haven't had time to try your patches yet or even
look at them.

What I wanted to ask was would it be possible to
extend the number of Source files the system could
handle.


Two is a stupid limitation.

The story I want is as follows

for each branch of versioning we would have another
level of source/changes

in other words source for 3.0
changes for 3.n
newchanges for 3.n.m
etc down to several levels.

That would be a big win.
The only file you would have to ship would be the
change file that matched the current level of image.
The high level changes would act as source.

We get recursive fractal behaviour and an easy way of
developing source and distributing changes. Much more
organic that the current way.

---

So questions.

Is it possible?

How many bits do we need to trade off from the other
address space?

How much work might it be to do?

Are there resources to do it?

-----

Yours in service, --Jerome Peace





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Both source files now with 512MB capacity Klaus D. Witzel

timrowledge
It's not a question of bits, it's a question of changing to a better  
structure for referencing the source code than an encrypted number  
pair rammed into a single SmallInteger. You could fairly easily use  
(for example) a database query if you wanted.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MAZEL TON - Lots of luck



Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Both source files now with 512MB capacity Klaus D. Witzel

Klaus D. Witzel
In reply to this post by Jerome Peace
On Tue, 22 Aug 2006 06:02:25 +0200, Peace Jerome wrote:
> Hi Klaus,
>
> Thank you for removing a limitation from squeak.

Would not have been possible without introduction of MethodProperties :)

> I haven't had time to try your patches yet or even
> look at them.
>
> What I wanted to ask was would it be possible to
> extend the number of Source files the system could
> handle.

Easy: SourceFiles is an instance of SourceFileArray which inherits from  
SequenceableCollection.

> Two is a stupid limitation.
>
> The story I want is as follows
>
> for each branch of versioning we would have another
> level of source/changes
>
> in other words source for 3.0
> changes for 3.n
> newchanges for 3.n.m
> etc down to several levels.
>
> That would be a big win.

I agree, this is worth some effort.

> The only file you would have to ship would be the
> change file that matched the current level of image.
> The high level changes would act as source.
>
> We get recursive fractal behaviour and an easy way of
> developing source and distributing changes. Much more
> organic that the current way.
>
> ---
>
> So questions.
>
> Is it possible?

Yes. I want it, so it is possible :)

> How many bits do we need to trade off from the other
> address space?

None (when my patch is used) besides that more tests are needed. The new  
file index is a regular instance variable (in MethodProperties) and even  
could point to a database in the way that Tim remarked in his response.

What I want the community to think about [loud] is, that migration can  
(but must not) address DoIt's as well (was suggested by Stef).

My plan is to scan [at least] all class definitions from the DoIt chunks  
and have them chronologically linked (like versions of methods are  
linked). In order to then access them, sort of "ClassProperties" would be  
necessary for the tail of that linked list; perhaps ClassOrganizer can  
store another remote string oop.

> How much work might it be to do?

Two areas of change I can see: 1) the "release" mechanism, which would be  
responsible for adding the next element to SourceFiles and 2) today the  
.changes have constant file index 2, this has to be adapted. The rest is  
already in place (to be precise the patch does not address coexistence of  
old and new "prior:" links but that will disappear automagically once a  
new set of the files was written).

> Are there resources to do it?

Yes. As discussed with Marcus (here some time ago) the patch waits for 3.9  
final. Until then I'd like to get a bit more than just an idea from where  
and how the historical .sources and .changes can/must be taken. As part of  
migration, the "prior:" link of all "headers" in these files needs to be  
rewritten.

I expect to see more inconsistencies in the current "prior:" links, like  
the two examples I posted earlier. This will require extra resources  
(especially the collective memory of the Squeak community) for finding  
solutions.

/Klaus


> -----
>
> Yours in service, --Jerome Peace