Re: Re: SqNumberParser refactoring

2008/8/31 Alejandro F. Reimondo <aleReimondo <at> smalltalking.net>:
> Hi,
>
>> The purpose of putting scripts on installer.pbwiki.com is so that those
>> scripts can be loaded into 'any' image with the minimum of Installer or
>> at best LPF loaded.
>
> The scripting idea is valuable when you want to "run" scripts (to
> produce output data) on a solid+fat+stable defined
> core of functions+components exposed by the scripting
> engine/compiler...
> It is not the case for smalltalk systems, where any change can
> be done on the system, during an installation the intent is to
> produce change in the system, and the most valuable attribute
> of the system itself is it´s stability.
> (a very diferent scenario to where use of scripting has
> proven to be good)
>
>> This scenario is intended to enable the user to see
>> and select what to apply to their own images.
>
> The real problem here is that "the user" (the owner of the
> system under my pov) must ask/respond without
> seen/understanding what will be injected and also without
> understanding some areas of the system that will be affected
> by the "script" (a script that is written by a person that do not
> know about the system it is been installed).

+1

Re: Re: SqNumberParser refactoring

2008/9/1 Alejandro F. Reimondo <aleReimondo <at> smalltalking.net>:
> Hi,
>
>> The purpose of putting scripts on installer.pbwiki.com is so that those
>> scripts can be loaded into 'any' image with the minimum of Installer or
>> at best LPF loaded.
>
> The scripting idea is valuable when you want to "run" scripts (to
> produce output data) on a solid+fat+stable defined
> core of functions+components exposed by the scripting
> engine/compiler...
> It is not the case for smalltalk systems, where any change can
> be done on the system, during an installation the intent is to
> produce change in the system, and the most valuable attribute
> of the system itself is it´s stability.
> (a very diferent scenario to where use of scripting has
> proven to be good)
>
>> This scenario is intended to enable the user to see
>> and select what to apply to their own images.
>
> The real problem here is that "the user" (the owner of the
> system under my pov) must ask/respond without
> seen/understanding what will be injected and also without
> understanding some areas of the system that will be affected
> by the "script" (a script that is written by a person that do not
> know about the system it is been installed).
>
> I consider that it is not enough to "see"/read the package
> intention, if the injection(ingestion?) of changes to the system

Re: Making a better Compiler for all

Re: Making a better Compiler for all

On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko <siguctua <at> gmail.com> wrote:
> Hello folks,
>
> during my visit at ESUG i had a conversation with Stephane, about
> different things, one of them is to make a better and cleaner compiler
> implementation.

I thought this was the purpose of the NewCompiler project.  Is that
project not good enough?  Or is this a request to make it standard?

-Ralph

Re: Making a better Compiler for all

On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:

> On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
>> Hello folks,
>>
>> during my visit at ESUG i had a conversation with Stephane, about
>> different things, one of them is to make a better and cleaner compiler
>> implementation.
>
> I thought this was the purpose of the NewCompiler project.

No, you cannot remove Squeak's compiler and use only NewCompiler, if that  
would have been your question.

/Klaus

>  Is that
> project not good enough?  Or is this a request to make it standard?
>
> -Ralph
>
>

Re: Re: Making a better Compiler for all

2008/9/1 Klaus D. Witzel <klaus.witzel <at> cobss.com>:
> On Mon, 01 Sep 2008 03:59:44 +0200, Ralph Johnson wrote:
>
>> On Sun, Aug 31, 2008 at 10:19 AM, Igor Stasenko wrote:
>>>
>>> Hello folks,
>>>
>>> during my visit at ESUG i had a conversation with Stephane, about
>>> different things, one of them is to make a better and cleaner compiler
>>> implementation.
>>
>> I thought this was the purpose of the NewCompiler project.
>
> No, you cannot remove Squeak's compiler and use only NewCompiler, if that
> would have been your question.
>
> /Klaus
>
>>  Is that
>> project not good enough?  Or is this a request to make it standard?
>>

Yes, the main question about it, why it didn't replaced old compiler?

There are some bad things in current compiler, which makes it really
hard to play with:
try implement a visitor pattern with its AST - you will go into
trouble very soon, because some nodes properties is not fully exposed,
or accessible in a cryptic way. That's why VMMaker, for instance,
using an extensions/patching to be able to reach all interesting
properties of parse nodes.
A bytecode generation is spead among AST nodes, and interesting, that
you can't insert some kind of analyzer or pre/postprocessor without
patching methods, because there is no separation in responsibility who
emits the bytecodes.A MethodNode returns you a hot baked
CompiledMethod instance. It would be good to make a bytecode
generation placed in separate class , which using a visitor pattern to
generate a bytecode.
There are also an agressive rewrite rules, sitting at early processing
stage which replacing original selectors like #ifTrue:{ifFalse:} or
#to:do: , so you can't see an original parsed AST from source code,
but getting already twisted preoptimized tree , which not reflects an
original source 1:1.

>> -Ralph
>>

--

-- 
Best regards,
Igor Stasenko AKA sig.

[ANN] First public test of SqueakLightII-dev.7201

I very proud to announce to all :

Thanks to Janko and Nico in this days and to Goran and Giovanni for his past
and present work, I a have a Kom+HttpView2+Aida+Scribo and more running

It's alpha, but is running.
So, with caution and until Smalltalks 2008, you was invited to help to have
a modular image which could grow to your needs.

Read previous post and swiki.

Action is on #squeak of IRC. NOW!!!

Again thanks to lots of people teaching me for be kind and ready to solve
odd troubles !

Edgar, trying to made Smalltalk and not JustTalk

[ANN] SqueakGTK

Hi,

A new version of SqueakGTK is published. I've corrected 2 annoying
bugs that make Squeak crashes.

Here is the roadmap of the next versions :
    * binaries for windows, mac os x, linux
    * save and restore the widgets
    * Support canvas inside cairo we can use the morphs with GTK :p
    * Improve all the tools
    * And off course correct the bugs -_-'
    * A new website

http://code.google.com/p/squeakgtk/

Cheers,
Gwenael Casaccio

Re: Re: Making a better Compiler for all

On Mon, Sep 1, 2008 at 2:13 AM, Klaus D. Witzel <klaus.witzel <at> cobss.com> wrote:

> No, you cannot remove Squeak's compiler and use only NewCompiler, if that
> would have been your question.

That was not really my question.

I thought that the purpose of the NewCompiler project was to replace
the old compiler.  Am I wrong?

If so, is this just another way of telling people to support the
NewCompiler project, or is it saying that we need a NewNewCompiler
project.

If not what is wrong with NewCompiler, and why can't it become the
standard Squeak compiler some day?

If you are saying we should all get behind NewCompiler, then we can
ask what needs to be done to finish it, but first I am asking whether
that is what you mean.

I've hacked the Squeak compiler a little and I think that everybody
who has done that will agree that it should be replaced.  As far as I
can see, the NewCompiler people have a good design, and it should be
possible use it in place of the old compiler, if not now, then with a
little more work.

-Ralph

Re: BabyUML has reached its goal

Hi Trygve:

As usual, a very interesting work from you.

I will invest some time reading more deeper to better understand your ideas.

I ever searched/thinked in better ways of produce software, and think
that with Smalltalk we have a big tool, but we are yet at the middle
of the road. May be BabyIDE go in such direction.

Thanks by share.

Cheers.
Germán.

2008/8/29 Edgar J. De Cleene <edgardec2001 <at> yahoo.com.ar>:
>
>
>
> El 8/28/08 9:00 AM, "Trygve Reenskaug" <trygver <at> ifi.uio.no> escribió:
>
>> The goal of the BabyUML project was to bridge the chasm between the code we
>> write at compile time and the networks of communicating objects that do the
>> work at runtime.
>>
>> The BabyIDE interactive development environment bridges this chasm . Its
>> foundation is the new DCI paradigm, its key stone is a variant of the Traits
>> stateless methods.
>>
>> Read the report and download the programs. You find all about it in the
>> BabyIDE home page
>>     http://heim.ifi.uio.no/~trygver/themes/babyide/babyide-index.html
>> <http://heim.ifi.uio.no/%7Etrygver/themes/babyide/babyide-index.html>
>>
>> Enjoy yourself while I'm relaxing in the mountains for the next seven days.
>> --Trygve
>
> Trygve:
>
> I always follow any project coming from you
>
> A few observations
> commonsense.pdf is not on the .zip.
> A .sar with the needed for work on 3.10 published in SqueakMap gives wider
> audience IMHO.
>
> Enjoy the Norway mountains.I afraid seven days is not enough to understand
> all this fundamental work.
>
> Edgar
>
>
>
>