Re: DebuggerUnwindBug>>testUnwindDebuggerWithStep

Norbert Hartl wrote:
> What does this
> 
> <primitive: 19> "Simulation guard" 
> 
> do?

It does nothing. It only indicates that the system will crash if that 
code ever gets simulated (usually due to atomicity violations).

> Hmmm, looks quite confusing to me as the suspendingList is
> only one element in size the whole time. Hmmm...

Yeah, indeed. That is interesting. I don't have the time to look at this 
right now but it may actually be the solution to the problem. I think 
that a strategically placed #suspend in completeStep: may solve this 
problem. I'll have to think about this more ...

> Anyway my conclusion is that the test in my first post can't work.

Not sure how you come to this conclusion. The test *doesn't* work but 
that indicates that a piece of the system is broken.

> Any suggestions which side needs a change?

Simulating "out of" a semaphore wait is broken. The debugger test is 
still valid btw, since it illustrates the behavior in a practical manner.

Cheers,
   - Andreas

Re: Bootstrapping (Subversion (was: Re: Perl is to CPAN as Squeak is to (what)?))

At Sun, 29 Jun 2008 07:31:26 -0500,
Ralph Johnson wrote:
> 
> Pavel Krivanek
> http://www.comtalk.eu/Squeak/98
> 
> On Sun, Jun 29, 2008 at 4:09 AM, Yoshiki Ohshima <yoshiki <at> vpri.org> wrote:
> 
> >  - Write a compiler in another language.  That can generates the bits
> >    that are same as CompiledMethods.  For a class definition, it
> >    creates (yes) the network of pointers.
> >
> >  - The compiler sticks the class definitions, method dictionaries,
> >    subclass structure, and compiled methods into a big "int*" array.
> >    The goal is to make that something just run, so for example, the
> >    stuff managed by ClassDescription (instanceVariable names and
> >    organization) don't have to be compiled.  Stuff like the source
> >    pointer is not needed at this stage.
> 
> The compiler doesn't have to be in another language.  What is
> important is that the compiler builds a Squeak image from a text file.
>  The compiler can be written in Smalltalk as long as it uses only the
> class definitions in the test file, not in the compiler's image.

  This is more or less settled but...

  If the compiler is written in Smalltalk, we would have a binary
image to store the compiler; and some people wouldn't like it.
Nonetheless, it can be in Slang and we can just show the translated C
code as if it is the "egg".

Re: Bootstrapping (Subversion (was: Re: Perl is to CPAN as Squeak is to (what)?))

> What Linux people proposing looks controversial to me.

  The attitude toward Etoys/Squeak vary widely among *them*, also.
Fortunately, the guys who are viciously bashing Etoys on the OLPC
devel list aren't the guys who make decisions there.  Hopefully a bit
by bit, we can make some progress.  That thread is great for these
decision makers because it is yet another example of how not to
discuss stuff^^;

-- Yoshiki

Re: The Primitive: I am not a number- I am a named prim! - SqueakPeople article

Re: C++ parser in Smalltalk?

On Tue, Jul 1, 2008 at 12:12 AM, Peter William Lount <peter <at> smalltalk.org> wrote:

C/C++ to Smalltalk translator anyone?

If I were doing this, I'd investigate making a back-end for GCC that generates Smalltalk bytecodes. Then we could compile many C, C++, Fortran and Java programs to the Squeak VM .

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Re: C++ parser in Smalltalk?

Re: Subversion (was: Re: Perl is to CPAN as Squeak is to (what)?)

On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:

> This is quite interesting.
> Really, if we could just avoid using file-based working directory and
> make image to be a kind of 'working directory' this would simplify
> things  a lot - no need to make file outs and synchronization is
> always made between current methods in image and git repository.
> Interesting, how much coding needed to connect image with git
> repository in that way.

One option would be to use FUSE (or something similar) to make the  
image appear to be a filesystem. That wouldn't be git-specific, and  
would even appease all the folks that want to edit their code with  
emacs.

Colin

Re: The Primitive: I am not a number- I am a named prim! - SqueakPeople article

On 30-Jun-08, at 6:02 PM, Michael van der Gulik wrote:

>
>
> On Tue, Jul 1, 2008 at 6:34 AM, tim Rowledge <tim <at> rowledge.org> wrote:
> I am trying to make time to post a few articles on some future  
> directions I consider interesting for the core system.
>
> First one is up at http://people.squeakfoundation.org/article/ 
> 89.html - do please comment on the relevant page, or even here.
>
> Does every numbered prim also have a name or named equivalent?

It's just a prim, ie a function somewhere.

I'm proposing that we name all those prims that are currently numbered  
- primitive 1 would become "primitiveAdd" in a similar manner to say  
"primitiveDisablePowerManager".  This would allow all prims to be  
built as plugin components, thereby allowing on the fly replacement of  
those plugins (making due allowance for handling retained state etc,  
of course). (It's sometihng I've been wanting to see done since 1988;  
I had discussions with Alan Schiffman & Peter Deutsch about it way  
before I even move to ParcPlace). We would lose the primitive table,  
saving a 8 kb or so. Oh and the *really* obsoleteIndexPrimitiveTable,  
saving another 8Kb or so.

Some code gets simplified, some space is saved, some flexibility is  
added, some bits are freed up in the CM header. THe downside is  
someone has to do some work.

tim
--
tim Rowledge; tim <at> rowledge.org; http://www.rowledge.org/tim
Advanced design: Upper management doesn't understand it.

Re: Subversion

Colin Putney wrote:
>
> On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
>
>> This is quite interesting.
>> Really, if we could just avoid using file-based working directory and
>> make image to be a kind of 'working directory' this would simplify
>> things  a lot - no need to make file outs and synchronization is
>> always made between current methods in image and git repository.
>> Interesting, how much coding needed to connect image with git
>> repository in that way.
>
> One option would be to use FUSE (or something similar) to make the 
> image appear to be a filesystem. That wouldn't be git-specific, and 
> would even appease all the folks that want to edit their code with emacs.
>
> Colin
>
>
It has been done

Keith