methods for license conversion

> - it contains 2919 methods
> - 1029 methods have no initials of the author hasn't subscribed the
> license conversion agreement so we have to rewrite them
> (http://comtalk.net/public/pub/KernelImage/20070704/authors.ods)
> - it is able to condense changes
> - it is able to evaluate unimplemented calls
> (http://comtalk.net/public/pub/KernelImage/20070704/info.txt)
> - it is able to print all objects and generate the image map in HTML
> form with reverse references
> (http://comtalk.net/public/pub/KernelImage/20070704/ImageMap.zip)
> - it has still 2MB (that's why we need the image analysis tool ;-)
> - it is able to load SUnit and run basic set of  tests without failures
> - platform specific code only for Linux
>
> I should point out that if I'm talking about possibility of loading
> Morphic into this image, I'm not talking about future or theoretical
> plans but about real possibility supported by successful experiments
> ;-)
>
> I think that we should define exactly what the term 'rewrite a method'
> means and find some people that want to help with license conversion
> of the image.
>
> Cheers,
> -- Pavel
>
>

>
>> Making a minimal system - either yor way or Craig's way - present  
>> an opportunity to start from a place with NO constraints arising  
>> from a previous framework that has to be kept limping along
>>
>> I would *love* to see a new, clean, designed UI/graphics system  
>> implemented that can take advantage of host windows, Cairo,  
>> freetype, etc. No, I'm *not* offering to design it.
>
> Wouldn't using Cairo automatically include host windows?
>
> Or do you mean a system should allow direct native windows as well  
> as through various libraries?

> I'm rather inclined to the idea that "Morphic Must Die!"
>
> Making a minimal system - either yor way or Craig's way - present an
> opportunity to start from a place with NO constraints arising from a
> previous framework that has to be kept limping along
>
> I would *love* to see a new, clean, designed UI/graphics system
> implemented that can take advantage of host windows, Cairo, freetype,
> etc. No, I'm *not* offering to design it.
>
> Come on people, be brave. Let's try to make a Smalltalk 2000 sometime
> before Smalltalk 3000 is due?

> > The real point though is simply that we can do something *different*
> > when we have tools that allow us to start from almost-scratch whilst
> > still having an existing system to build the new code in. Spoon can
> > provide a way to develop a chunk of code in an image with all the tools
> > we're currently used to, save it out as a spoonful and have the 'new '
> > image be spoon-fed the package. It's like cross-development without so
> > much cross :-)
>
> I think that sounds great. But don't we need Spoon first?<s>
>
> I also think that such a project would be an excellent opportunity to show
> the usefulness of traits.
>
>         ===Blake===
>
>

> On 06/07/07, Blake <[hidden email]> wrote:
>> On Thu, 05 Jul 2007 14:14:50 -0700, tim Rowledge  
>> <[hidden email]> wrote:
>>
>> > Don't know the answer to that one; I was under the impression  
>> that Cairo
>> > was 'just' graphics but I haven't really researched it per se.  
>> Given
>>
>> It's vector graphics, though you can build a UI with it. I  
>> (incorrectly)
>> thought it mapped to native tools.
>>
> About Cairo, as noted on site:
> Cairo is a 2D graphics library with support for multiple output
> devices. Currently supported output targets include the X Window
> System, Win32, image buffers, PostScript, PDF, and SVG file output.
> Experimental backends include OpenGL (through glitz), Quartz, and XCB.
>
> 1 fact: i assume it proposes a cross-platform layer of abstraction on
> top of existing graphics libraries (like DirecX/OpenGL whatever).
> 2nd fact, i dont like: its 2D only.

> This raises a more general question of how to go about extending
> Squeak, use external libraries or attempt to reproduce functionality
> within Squeak. I often see-saw between the two, usually based on
> performance-vs-flexibility (if I conveniently ignore questions
> regarding ability/time to implement, lol). Personally I think external
> libs should be used where they have reached a level of maturity... and
> are free... and are available for at least the big three OS's. Plus
> there are areas in Squeak that simply have not and maybe cannot keep
> up with the excellent effort put into some external libs (I'm thinking
> video, flash, etc, but I'm sure there are other areas).
>
> OTOH, the more ex-libs are used the more Squeak becomes a
> scripting-like tool (not a big bad thing IMHO) and the further it gets
> from being the ideal computing environment with access to every level
> (VM not withstanding). I drool at the idea of the latter but at the
> end of the day I would choose practicality over ideals. I also detest
> the idea of wasted effort, by anyone, going into "recreating the
> wheel". For instance, I'm considering creating a media-centre type
> image and my conclusion is it would be madness not to utilise ex-libs.
>
> Bert, do you know if the Impara work is (or will be) publicly  
> available?

> On Jul 9, 2007, at 1:10 , sig wrote:
>
> > On 06/07/07, Blake <[hidden email]> wrote:
> >> On Thu, 05 Jul 2007 14:14:50 -0700, tim Rowledge
> >> <[hidden email]> wrote:
> >>
> >> > Don't know the answer to that one; I was under the impression
> >> that Cairo
> >> > was 'just' graphics but I haven't really researched it per se.
> >> Given
> >>
> >> It's vector graphics, though you can build a UI with it. I
> >> (incorrectly)
> >> thought it mapped to native tools.
> >>
> > About Cairo, as noted on site:
> > Cairo is a 2D graphics library with support for multiple output
> > devices. Currently supported output targets include the X Window
> > System, Win32, image buffers, PostScript, PDF, and SVG file output.
> > Experimental backends include OpenGL (through glitz), Quartz, and XCB.
> >
> > 1 fact: i assume it proposes a cross-platform layer of abstraction on
> > top of existing graphics libraries (like DirecX/OpenGL whatever).
> > 2nd fact, i dont like: its 2D only.
>
> Since Morphic is 2D, too, that's a perfect match.
>

> > I prefer to directly use OpenGL (which is already a cross-platform)
> > and provides enough capabilities to develop a UI using 2D graphics or
> > 3D (like composite desktops/games e.t.c). I think using OpenGL
> > directly for creating UI is better choice for squeak.
> > I implemented a scratch replacement of Canvas/Display stuff to use GL
> > via FFI for drawing morphic with squeak. Premiliary, based on rough
> > calculations it renders desktop 3 to 5 times faster than currently
> > used Balloon/BitBlt.
>
> Nice. I'd expect roughly the same from a native Cairo back-end.
>
> > Also, i noticed that changes needed to make use
> > of GL with morphic architecture is minimal, and opening a wide range
> > perspective for creating a stunning and fast UI for squeak, not
> > limited by third-party libraries, which providing own abstraction
> > layer(s).
>
> If speed is all you care about, then I agree. Recreating the quality
> Cairo provides based on an OpenGL layer is hard, though. Cairo is not
> so much about abstraction, but about providing a consistent rendering
> model and reliable high-quality results on any 2D output device from
> screen to printers.
>

> > Anyways, to use modern graphics cards features with squeak, we have no
> > choice but to use some of the existing external libraries.
>
> Agreed.
>
> > And OpenGL is a winner here, without a doubt.
>
> I beg to differ. For one, there are two major platform with
> unreliable OpenGL hw support.
>
> But more importantly, OpenGL goes for quick-and-dirty, whereas Cairo
> does the-right-thing. Cairo chooses quality and reliability over raw
> performance (while performance still is adequate for interactive
> use). For a comparison and introduction see, for example,
>
>         http://people.freedesktop.org/~keithp/tutorials/cairo/cairo-
> tutorial.pdf
>
> This is not to say OpenGL is useless, far from it. But for high-
> quality 2D graphics, Cairo is clearly the better choice, *and* it's
> simple to use both if you need both 2D and 3D graphics:
>
>         http://cairographics.org/OpenGL/
>
> The current Cairo-backed graphics system for Squeak ("Rome") uses the
> software rasterizer of Cairo, which does not give a lot of speed-up
> (but looks awesome). However, folks at impara have combined Rome and
> HostWindows, thus rendering directly to OS windows using Cairo. That
> should be much faster while still providing high quality. Not sure of
> the current state of this, though.
>
> - Bert -
>
>
>
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En
> nombre de sig
> Enviado el: Domingo, 08 de Julio de 2007 20:10
> Para: The general-purpose Squeak developers list
> Asunto: Re: methods for license conversion
>
> On 06/07/07, Blake <[hidden email]> wrote:
> > On Thu, 05 Jul 2007 14:14:50 -0700, tim Rowledge
> <[hidden email]> wrote:
> >
> > > Don't know the answer to that one; I was under the
> impression that
> > > Cairo was 'just' graphics but I haven't really researched
> it per se.
> > > Given
> >
> > It's vector graphics, though you can build a UI with it. I
> > (incorrectly) thought it mapped to native tools.
> >
> About Cairo, as noted on site:
> Cairo is a 2D graphics library with support for multiple
> output devices. Currently supported output targets include
> the X Window System, Win32, image buffers, PostScript, PDF,
> and SVG file output.
> Experimental backends include OpenGL (through glitz), Quartz, and XCB.
>
> 1 fact: i assume it proposes a cross-platform layer of
> abstraction on top of existing graphics libraries (like
> DirecX/OpenGL whatever).
> 2nd fact, i dont like: its 2D only.
>
> I prefer to directly use OpenGL (which is already a
> cross-platform) and provides enough capabilities to develop a
> UI using 2D graphics or 3D (like composite desktops/games
> e.t.c). I think using OpenGL directly for creating UI is
> better choice for squeak.
> I implemented a scratch replacement of Canvas/Display stuff
> to use GL via FFI for drawing morphic with squeak.
> Premiliary, based on rough calculations it renders desktop 3
> to 5 times faster than currently used Balloon/BitBlt. Also, i
> noticed that changes needed to make use of GL with morphic
> architecture is minimal, and opening a wide range perspective
> for creating a stunning and fast UI for squeak, not limited
> by third-party libraries, which providing own abstraction layer(s).
> Anyways, to use modern graphics cards features with squeak,
> we have no choice but to use some of the existing external
> libraries. And OpenGL is a winner here, without a doubt.
>
> > > The real point though is simply that we can do something
> *different*
> > > when we have tools that allow us to start from
> almost-scratch whilst
> > > still having an existing system to build the new code in.
> Spoon can
> > > provide a way to develop a chunk of code in an image with all the
> > > tools we're currently used to, save it out as a spoonful
> and have the 'new '
> > > image be spoon-fed the package. It's like
> cross-development without
> > > so much cross :-)
> >
> > I think that sounds great. But don't we need Spoon first?<s>
> >
> > I also think that such a project would be an excellent
> opportunity to
> > show the usefulness of traits.
> >
> >         ===Blake===
> >
> >
>

>
>> This raises a more general question of how to go about extending
>> Squeak, use external libraries or attempt to reproduce functionality
>> within Squeak. I often see-saw between the two, usually based on
>> performance-vs-flexibility (if I conveniently ignore questions
>> regarding ability/time to implement, lol). Personally I think  
>> external
>> libs should be used where they have reached a level of maturity...  
>> and
>> are free... and are available for at least the big three OS's. Plus
>> there are areas in Squeak that simply have not and maybe cannot keep
>> up with the excellent effort put into some external libs (I'm  
>> thinking
>> video, flash, etc, but I'm sure there are other areas).
>>
>> OTOH, the more ex-libs are used the more Squeak becomes a
>> scripting-like tool (not a big bad thing IMHO) and the further it  
>> gets
>> from being the ideal computing environment with access to every level
>> (VM not withstanding). I drool at the idea of the latter but at the
>> end of the day I would choose practicality over ideals. I also detest
>> the idea of wasted effort, by anyone, going into "recreating the
>> wheel". For instance, I'm considering creating a media-centre type
>> image and my conclusion is it would be madness not to utilise ex-
>> libs.
>>
>> Bert, do you know if the Impara work is (or will be) publicly  
>> available?
>
> This was related to Sophie, and everything Sophie-related is open  
> source and publicly available. I think this one would be HostWindow-
> Rome at
>
> http://source.impara.de/HostWindows.html
>
> - Bert -
>
>
>
>

>> I have prepared an image with small code base that is ready for
>> license conversion and is able to load a sequence of packages up to
>> working Morphic system.
>
> I'm rather inclined to the idea that "Morphic Must Die!"
>
> Making a minimal system - either yor way or Craig's way - present  
> an opportunity to start from a place with NO constraints arising  
> from a previous framework that has to be kept limping along
>
> I would *love* to see a new, clean, designed UI/graphics system  
> implemented that can take advantage of host windows, Cairo,  
> freetype, etc. No, I'm *not* offering to design it.
>
> Come on people, be brave. Let's try to make a Smalltalk 2000  
> sometime before Smalltalk 3000 is due?
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: YII: Yield to Irresistable Impulse
>
>
>
>

> "Pavel Krivanek" <[hidden email]> writes:
>> - 1029 methods have no initials of the author hasn't subscribed the
>> license conversion agreement so we have to rewrite them
>> (http://comtalk.net/public/pub/KernelImage/20070704/authors.ods)
>
> While rewriting is the simplest solution, it is also labor-intensive.
>
> Most likely non-initialled methods are ancient ones dating from Squeak
> 1.0 or even earlier.  Suppose we did a comparison and realized that
> most of them were from Squeak 1.0.  Would we then be able to identify
> a small number of people who definitely wrote it?
>
> Or, would that doubly mean we have to rewrite the code in question??
> What is the legal status of methods from Squeak 1.0?
>