Re: [Pharo-project] Keyboard shortcuts cheatsheet

2010-03-06 Thread Miguel Enrique Cobá Martinez
El sáb, 06-03-2010 a las 15:05 -0800, fstephany escribió:
> Hi there,
> 
> I've made a small cheatsheet based on an email from Mariano
> (http://n4.nabble.com/Regarding-the-shortcuts-td1298842.html#a1298842).
> 
> http://tulipemoutarde.be/documents/pharo_cheat_sheet.pdf

Cool, thanks

> 
> I've removed those that were not working or not relevant. Some are still
> weird though (are cmd+K or cmd+G actually used by someone ?)
> 
> If you have any suggestions/critics or want to add your favorite shorcut to
> the list, just let me know.
> 
> Cheers,
> 
> Francois 

-- 
Miguel Cobá
http://miguel.leugim.com.mx


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] Keyboard shortcuts cheatsheet

2010-03-06 Thread fstephany

Hi there,

I've made a small cheatsheet based on an email from Mariano
(http://n4.nabble.com/Regarding-the-shortcuts-td1298842.html#a1298842).

http://tulipemoutarde.be/documents/pharo_cheat_sheet.pdf

I've removed those that were not working or not relevant. Some are still
weird though (are cmd+K or cmd+G actually used by someone ?)

If you have any suggestions/critics or want to add your favorite shorcut to
the list, just let me know.

Cheers,

Francois 
-- 
View this message in context: 
http://n4.nabble.com/Keyboard-shortcuts-cheatsheet-tp1583170p1583170.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [squeak-dev] Re: [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Julian Fitzell
On Sat, Mar 6, 2010 at 12:54 PM, Paolo Bonzini  wrote:
>> We think that one of the most important reasons why we failed in 2009 is
>> that Google was looking for bigger communities that Squeak. This is why
>> this year we all go under the ESUG umbrella. We present ESUG as the
>> mentor organization and we cover ALL open-source Smalltalk dialects, not
>> only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all
>> invited to participate. Also cross platform projects like Seaside,
>> AidaWeb, Magma, etc are welcome.
>
> Here is a list of ideas from me, all more or less involving cross-dialect
> pollination.  These are based on my preferences, from most to least
> preferred
>
> 1) GNU Smalltalk includes a refactored version of Swazoo that supports SCGI
> and is also faster in general.  Start from there and backport the changes to
> Squeak/Pharo.  Use Seaside's Grease cross-dialect compatibility layer to get
> rid of (most of) the Sport dependency.
>
> 2) Convert existing cross-platform projects to use Grease.  Demonstrate them
> using two-three dialects (VW, Squeak, GST).  Discuss possible extensions to
> Grease and implement them.  Document Grease extension based on the formalism
> of the ANSI standard.
>
> 3) I agreed with the FSF to relicense GNU Smalltalk's file system classes
> under MIT license.  Port them to at least two other dialects (Squeak/Pharo
> count as one).  Think of cool ways to use them.  Possibly work out how to
> integrate them into Grease and make Seaside use them.

I think I'd be willing to be a mentor for anything Grease- or
Seaside-related, though I might need to run that by my new employer
depending on what the project ends up being.

The above are good ideas. Also, off the top of my head:

+ Take the best parts of Seaside and Swazoo's HTTP protocol classes
and create an HTTP package that could be optionally loaded with Grease
and used by multiple projects.

+ Someone else suggested porting Monticello to Smalltalk/X. The same
could be done for VA Smalltalk and a full port with UI for VW.

+ I'd really love to see a single RefactoringBrowser package that
could be loaded on all the platforms using Grease. I have no idea if
there's any chance of buy-in from the vendors on that one; maybe it
would need a new class name prefix so it could be loaded in
parallel...

Those are just random mind wanderings...

Julian

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] About using initialize

2010-03-06 Thread Chris Muller
Even though Object>>#initialize doesn't do anything, I still recommend
calling "super initialize" just for.  If you're doing an allocation
anyway, one super call ot a method that does nothing will not be a
performance issue.  But I feel is it is better-form to call super.


On Sat, Mar 6, 2010 at 3:24 PM, Stéphane Ducasse
 wrote:
> Hi guys
>
> I browsed a lot of code with jb friday and I saw that lot of classes that 
> predate the automatic initialize
> introduction (squeak 3.7) do not have a nice initialize methods.  In 
> particular old tools, have a particular style.
> I wanted to raise this point. I would really like to have classes that take 
> responsibilities to initialize objects with
> decent/default instance variables. It will make the code easier to understand 
> and evolve.
> If you have some (counter) arguments I'm all ears.
>
> Stef
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [update 1.1] #11247

2010-03-06 Thread Stéphane Ducasse
argh
I will check that.

Stef

> Don't forget that dragging a picture file into the Pharo main window
> makes a new SketchMorph...
> 
> Reards, Gary
> 
> On Sat, 2010-03-06 at 22:10 +0100, Stéphane Ducasse wrote: 
>> 11247
>> -
>> 
>> - Issue 2102: Fix the fact that local temp can shadow silently instance 
>> variable CompilerTests Tx lukas and jorge
>> 
>> -  Issue 2117:   methodComment (good idea laurent)
>>  
>> -  Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next 
>> step.
>> 
>> stef
>> 
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


[Pharo-project] [update 1.1] #11249

2010-03-06 Thread stephane ducasse
11249
-

-  Issue 2114:  Enhance SqNumberParser error handling inside Compiler. Tx 
nicolas
-  Issue 2116:  Compiler sometimes return nil rather than diagnosing the 
problem. Tx nicolas

- Issue 2118: 1) Let unicode leading Char be zero (only 2 methods).
Arbitrarily solve the Russian/Nepalese environment conflict.
-- SOMEONE HAS TO CHECK WHAT SHOULD THE POLICY BE... --
(I guess a non issue except for OLPC Etoys)

2) Prepare a TextStopConditions object for handling endOfRun/crossedX without 
breaking a macron.

3) After loading, you should execute: EncodedCharSets initialize.

Thanks nicolas

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Trying to build alien plugin in linux

2010-03-06 Thread Eliot Miranda
2010/3/4 Javier Pimás 

> Also I have the theory that the problem may be related to some
> -fomit-frame-pointer hidden in some place that forces code to use references
> relative to esp instead of ebp.


Ah, that's *very* important.  The plugin must *not* be built with
-fomi-frame-pointer.  In fact it needs -fno-omit-frame-pointer adding to
Makefile.inc et al to ensure it always includes the frame pointer.



>
>
> On Fri, Mar 5, 2010 at 1:20 AM, Javier Pimás 
> wrote:
>
>> Wiii. All tests passing now!!
>>
>> You were right, this func had so many variables that gcc was reserving
>> some local space to do some intermediate calculations.
>>
>> To make the story short defining
>> # define STACK_ALIGN_BYTES 16
>> solved it.
>>
>> After a lot of debugging I discovered that alloca was aligning the stack,
>> allocating more space than necesary, and placing the args not starting from
>> esp but from esp plus some offset. Adding getsp(argvec) to move argvec to
>> the top of the stack didn't solve the problem because the code that pushes
>> the args also overwrites it (don't know why, it's like alloca augmented the
>> frame in the middle?).
>>
>> So, that define fixed everything, and
>>
>> #if __APPLE__ && __MACH__ && __i386__
>> # define STACK_ALIGN_BYTES 16
>> #endif
>>
>> should be changed accordingly (to something I don't know what). In my case
>> I'm using gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1.
>>
>> Thanks for all the help!
>>
>> Regards,
>>Javier.
>>
>>
>>
>> On Wed, Mar 3, 2010 at 2:36 PM, Javier Pimás 
>> wrote:
>>
>>> Exactly, that's what confuses me most! The function doesn't even have
>>> locals:
>>>
>>> EXPORT(LONGLONG) ffiTestLongLong10a2(char c1, char c2, char c3, char c4,
>>> char c5, char c6, char c7, char c8, char c9, char c10, LONGLONG i1, LONGLONG
>>> i2) {
>>> return c1+c2+c3+c4+c5+c6+c7+c8+c9+c10+i1 + i2;
>>> }
>>>
>>> I'm quite sure it's substracting because I see the memory contents, and
>>> the disassembly is this (notice how it accumulates the result in edx):
>>>
>>> 0x75d32725 :   movsbl -0x1c(%ebp),%edx
>>> 0x75d32729 :   movsbl -0x20(%ebp),%eax
>>> 0x75d3272d :   add%eax,%edx
>>> 0x75d3272f :   movsbl -0x24(%ebp),%eax
>>> 0x75d32733 :   add%eax,%edx
>>> 0x75d32735 :   movsbl -0x28(%ebp),%eax
>>> 0x75d32739 :   add%eax,%edx
>>> 0x75d3273b :   movsbl -0x2c(%ebp),%eax
>>> 0x75d3273f :   add%eax,%edx
>>> 0x75d32741 :   movsbl -0x30(%ebp),%eax
>>> 0x75d32745 :   add%eax,%edx
>>> 0x75d32747 :   movsbl -0x34(%ebp),%eax
>>> 0x75d3274b :   add%eax,%edx
>>> 0x75d3274d :   movsbl -0x38(%ebp),%eax
>>> 0x75d32751 :   add%eax,%edx
>>> 0x75d32753 :   movsbl -0x3c(%ebp),%eax
>>> 0x75d32757 :   add%eax,%edx
>>> 0x75d32759 :   movsbl -0x40(%ebp),%eax
>>> 0x75d3275d :   lea(%edx,%eax,1),%eax
>>> 0x75d32760 :   mov%eax,%edx
>>> 0x75d32762 :   sar$0x1f,%edx
>>> 0x75d32765 :   add-0x48(%ebp),%eax
>>> 0x75d32768 :   adc-0x44(%ebp),%edx
>>> 0x75d3276b :   add-0x50(%ebp),%eax
>>> 0x75d3276e :   adc-0x4c(%ebp),%edx
>>> 0x75d32771 :   add$0xbc,%esp
>>> 0x75d32777 :   pop%ebx
>>> 0x75d32778 :   pop%esi
>>> 0x75d32779 :   pop%edi
>>> 0x75d3277a :   pop%ebp
>>> 0x75d3277b :   ret
>>>
>>> This is really weird! Why could gcc compiled it flipped? I'll continue
>>> looking.
>>>
>>> Regards,
>>>Javier.
>>>
>>> 2010/3/3 Eliot Miranda 
>>>
>>>

 2010/3/3 Javier Pimás 

 Ok, this is way nicer. The line that was missing and that seems to solve
> all this is
>
> self initializeSpecialObjectIndices.
>
> which I think should be placed in Alien>>#initialize just before
>
> self ensureInSpecialObjectsArray.
>
> but then I don't know why it should ensure anything that is done just
> before.
>
> With that I it's really close to work. After a few hours I understood
> the way tests are done. In Alien plugin you integrated a couple of 
> exported
> functions (ffiTest*), which you then call in the tests. These funcs do
> simple stuff like adding and returning the result, so you can compare, am 
> I
> right?
>
> Then I realized that (at least in linux) the tests won't work if you
> compile as internal (there won't be a .so, so you won't be able to load 
> the
> C test functions!).
>
> Now with the small fix I added, and compiling as external, I can see
> that it's actually almost almost working, bt I get these test results:
> 36 run, 17 passed, 19 failures, 0 errors (had to remove
> testCallingSquenceString because it crashed the VM). Notice that before I
> got 20 errors and 0 failures. This is because the results are wrong.
>
>
> I debugged the code with ddd to see what's happening, and I can see
> that everything is going nice before the actual function call,

Re: [Pharo-project] [update 1.1] #11247

2010-03-06 Thread Gary Chambers
Don't forget that dragging a picture file into the Pharo main window
makes a new SketchMorph...

Reards, Gary

On Sat, 2010-03-06 at 22:10 +0100, Stéphane Ducasse wrote: 
> 11247
> -
> 
> - Issue 2102: Fix the fact that local temp can shadow silently instance 
> variable CompilerTests Tx lukas and jorge
> 
> -  Issue 2117:methodComment (good idea laurent)
>   
> -  Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next 
> step.
> 
> stef
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Pharo-project] About using initialize

2010-03-06 Thread Stéphane Ducasse
Hi guys

I browsed a lot of code with jb friday and I saw that lot of classes that 
predate the automatic initialize
introduction (squeak 3.7) do not have a nice initialize methods.  In particular 
old tools, have a particular style.
I wanted to raise this point. I would really like to have classes that take 
responsibilities to initialize objects with 
decent/default instance variables. It will make the code easier to understand 
and evolve.
If you have some (counter) arguments I'm all ears.

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


[Pharo-project] [update 1.1] #11247

2010-03-06 Thread Stéphane Ducasse
11247
-

- Issue 2102: Fix the fact that local temp can shadow silently instance 
variable CompilerTests Tx lukas and jorge

-  Issue 2117:  methodComment (good idea laurent)

-  Convert logo from sketchMorph to imageMorph for SketchMorphRemoval next step.

stef

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Mariano Martinez Peck
A little correction. At the beginning I though only open-source Smalltalk
dialects were possible, but now Janko let me know that non open-source
dialects are welcome too. What really has to be open-source is the
project/idea in particular, but the Smalltalk dialect in itself can be non
open-source.

Sorry for the noise.

Mariano

On Sat, Mar 6, 2010 at 1:04 PM, Mariano Martinez Peck  wrote:

> Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup
> or second admin is Janko Mivšek. As you may know, Squeak has participated in
> GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we
> will succeed this year but we will try to do as much as possible.
>
> We think that one of the most important reasons why we failed in 2009 is
> that Google was looking for bigger communities that Squeak. This is why this
> year we all go under the ESUG umbrella. We present ESUG as the mentor
> organization and we cover ALL open-source Smalltalk dialects, not only
> Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to
> participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc
> are welcome.
>
> 
> It is a Google program that support (money) students to work on different
> open-source projects. Google doesn't talk or manage directly to the students
> but trough "Mentoring Organisations". Those organizations have to apply to
> GSoC. They have to give a lot of information, included a list of
> ideas/projects. Each project has a description and a mentor. Then the
> students apply for each project. If the organization gets selected by Google
> they will tell you how many "slots" they give. Suppose they give 5 but we
> have 20 projectsthen we vote and the most voted projects win. The
> student has to do the project and the mentor has to help and guide him. The
> mentor receives 500 USD and the student 4500USD.
> For more information read: http://code.google.com/soc/
> 
>
> The most important thing is the deadlines we have. We started late so we
> are very near to the first deadline which is 12/03/2010 (less than one
> week). For that deadline we need to submit all the information of the mentor
> organization (answering several questions) and give the list of
> ideas/projects and the mentors of that.
>
> We have created a webpage (Thanks Janko!!) where we will put all the
> information. We will make this page public soon (we still need to review a
> couple of things).
> But for the moment we would REALLY appreciate if tell us your ideas. To do
> this, just answer to this email. Then we will collect the information and
> put in the website. For each idea you need:  a short title and a paragraph
> (for the moment) explaining the idea.
> After, we need that the people that are willing to be mentors start to
> apply as mentors...please, consider yourself being mentor. Sometimes it is
> not that difficult. I mean, don't be shy as sometimes being helpful, being
> aware of the dates, answering emails, etc is more important than the
> Smalltalk knoweldege. We can have a lot of ideas, but we need also mentors
> for that. We even would need a "substitute" for each mentor...
>
> Just as an example you can see the ideas of the previous years:
> 2007: http://wiki.squeak.org/squeak/5936
> 2008: http://wiki.squeak.org/squeak/6031
> 2009: http://wiki.squeak.org/squeak/6120
>
> That's all for the moment.
>
> Cheers
>
> Mariano
>
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Having fun with booleans

2010-03-06 Thread csrabak

 Yes ;-) in fact Andrés Valloud wrote a book "Fundamentals of Smalltalk 
Programming Technique" which he discusses the theme of Booleans in Chapter 3 
and specifically the optimization you discovered in 3.2.1.

--
Cesar Rabak


Em 05/03/2010 04:22, Igor Stasenko < siguc...@gmail.com > escreveu:
Hello,
I just realized, that one can completely avoid using ifTrue/ifFalse
branches, but use #or: and #and: instead.

a > b ifTrue: [ ... ]
could be written as:
a > b and: [ ... ]

a > b ifFalse: [ ... ]
could be written as:
a > b or: [ ... ]

and
a > b ifTrue: [ self foo ] ifFalse: [ self bar ]
could be written as:

a > b and: [ self foo]; or:[ self bar ]

:)

-- 
Best regards,
Igor Stasenko AKA sig.

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Danny Chan
Am Samstag, 6. März 2010 10:41:36 schrieb Torsten Bergmann:
> Hi Danny,
> 
> > I am the first to acknowledge that this is your project.
> 
> No, no - it is not mine or yours. It is "Pharo Help" and it is
> "our" project - that's why the repo is open and the code is MIT!
> 
> Didnt you see the ;) behind my statements!

I did, but forgot to add one behind mine;)

> 
> >And I am also the first one to admit that my code is not great
> 
> How do you measure the greatness of code? ;)
> 
> Dont by shy! You idea and code is a great addition since we can
> and will definitely use it. Anything I've said is that I want
> to restructure it to align it with my design ideas
> (which I was not yet able to fully communicate since I'm in the
> midst of changing the original design)

And I am looking forward to seeing it. OK, need to go back to singing, she's 
starting to complain because I stopped while reading email...

Danny

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Polymorph fixes

2010-03-06 Thread Gary Chambers
Thanks to Alain for helping test the changes...

Regards, Gary

- Original Message - 
From: "Gary Chambers" 
To: 
Sent: Saturday, March 06, 2010 5:55 PM
Subject: Re: [Pharo-project] Polymorph fixes


Hopefully I'll be able to make a new mcz for merging on Monday, anyone can
request a change set from me in the meantime...

Regards, Gary

- Original Message - 
From: "Gary Chambers" 
To: 
Sent: Saturday, March 06, 2010 5:53 PM
Subject: Re: [Pharo-project] Polymorph fixes


Sorry that the fixes to table layouts are causing problems...
The two problems are that:

1 *invalid* hResizing/vResizing symbols now cause different behaviour
(fixing now, for Polymorph Morph construction)
2  layout cell positioning now works as (I believe) originally
intended... hence some adjustments to user code

Good that bug fixes hilight misuse, some by myself due to typos ;-)

Regards, Gary

- Original Message - 
From: "Stéphane Ducasse" 
To: 
Sent: Monday, March 01, 2010 7:34 PM
Subject: Re: [Pharo-project] Polymorph fixes


> Thanks.
> I will give a try but may be we have a bug in scriptLoader :)
>
> Stef
> On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote:
>
>> A few fixes on SqueakSource.
>>
>> Polymorph-Widgets-gvc.24
>> Polymorph-Tools-Diff-gvc.24
>>
>> Notably:
>>
>> Table layout of submorphs with #shrinkWrap attributes.
>> Themeing of menu item text colours to help Hilaire in his Sugar theme
>> efforts. ThemeSettings integration left for another time...
>> Wrong "sides" for "compare to current" when using diff tools in change
>> sets (versions browser etc.).
>> Prevention of window dragging from submorphs promoted from StandardWindow
>> to SystemWindow (deals with oddities when click-dragging from
>> submorphs... offset would be wrong and window "jumps").
>> Wrong colours for faded background windows in Watery themes.
>> Fix colours in W2K theme (requires class-side reinitialisation of
>> defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing
>> theme).
>> Toolbars now Panel-based to adapt to pane colour.
>> DockingBar based menus now deal with mouseFocus correctly.
>>
>>
>> Regards, Gary
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Polymorph fixes

2010-03-06 Thread Gary Chambers
Hopefully I'll be able to make a new mcz for merging on Monday, anyone can 
request a change set from me in the meantime...

Regards, Gary

- Original Message - 
From: "Gary Chambers" 
To: 
Sent: Saturday, March 06, 2010 5:53 PM
Subject: Re: [Pharo-project] Polymorph fixes


Sorry that the fixes to table layouts are causing problems...
The two problems are that:

1 *invalid* hResizing/vResizing symbols now cause different behaviour
(fixing now, for Polymorph Morph construction)
2  layout cell positioning now works as (I believe) originally
intended... hence some adjustments to user code

Good that bug fixes hilight misuse, some by myself due to typos ;-)

Regards, Gary

- Original Message - 
From: "Stéphane Ducasse" 
To: 
Sent: Monday, March 01, 2010 7:34 PM
Subject: Re: [Pharo-project] Polymorph fixes


> Thanks.
> I will give a try but may be we have a bug in scriptLoader :)
>
> Stef
> On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote:
>
>> A few fixes on SqueakSource.
>>
>> Polymorph-Widgets-gvc.24
>> Polymorph-Tools-Diff-gvc.24
>>
>> Notably:
>>
>> Table layout of submorphs with #shrinkWrap attributes.
>> Themeing of menu item text colours to help Hilaire in his Sugar theme
>> efforts. ThemeSettings integration left for another time...
>> Wrong "sides" for "compare to current" when using diff tools in change
>> sets (versions browser etc.).
>> Prevention of window dragging from submorphs promoted from StandardWindow
>> to SystemWindow (deals with oddities when click-dragging from
>> submorphs... offset would be wrong and window "jumps").
>> Wrong colours for faded background windows in Watery themes.
>> Fix colours in W2K theme (requires class-side reinitialisation of
>> defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing
>> theme).
>> Toolbars now Panel-based to adapt to pane colour.
>> DockingBar based menus now deal with mouseFocus correctly.
>>
>>
>> Regards, Gary
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Polymorph fixes

2010-03-06 Thread Gary Chambers
Sorry that the fixes to table layouts are causing problems...
The two problems are that:

1 *invalid* hResizing/vResizing symbols now cause different behaviour 
(fixing now, for Polymorph Morph construction)
2  layout cell positioning now works as (I believe) originally 
intended... hence some adjustments to user code

Good that bug fixes hilight misuse, some by myself due to typos ;-)

Regards, Gary

- Original Message - 
From: "Stéphane Ducasse" 
To: 
Sent: Monday, March 01, 2010 7:34 PM
Subject: Re: [Pharo-project] Polymorph fixes


> Thanks.
> I will give a try but may be we have a bug in scriptLoader :)
>
> Stef
> On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote:
>
>> A few fixes on SqueakSource.
>>
>> Polymorph-Widgets-gvc.24
>> Polymorph-Tools-Diff-gvc.24
>>
>> Notably:
>>
>> Table layout of submorphs with #shrinkWrap attributes.
>> Themeing of menu item text colours to help Hilaire in his Sugar theme 
>> efforts. ThemeSettings integration left for another time...
>> Wrong "sides" for "compare to current" when using diff tools in change 
>> sets (versions browser etc.).
>> Prevention of window dragging from submorphs promoted from StandardWindow 
>> to SystemWindow (deals with oddities when click-dragging from 
>> submorphs... offset would be wrong and window "jumps").
>> Wrong colours for faded background windows in Watery themes.
>> Fix colours in W2K theme (requires class-side reinitialisation of 
>> defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing 
>> theme).
>> Toolbars now Panel-based to adapt to pane colour.
>> DockingBar based menus now deal with mouseFocus correctly.
>>
>>
>> Regards, Gary
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Paolo Bonzini
On 03/06/2010 03:54 PM, Gilad Bracha wrote:
>>> You_can_  write an Objective-C binding using CObject (as in, it's
>>> been done).  The painful part is converting NSArray<->  Array and
>>> NSString<->  String.
>>>
>>> However, nice-looking bindings will always have a part written in
>>> C that will be VM-dependent, which is why I put this project
>>> last.  It is much less useful than it looks.
>
> Inteoperating smoothly with the rest of the world is very useful.

I fully agree.  But there's so much more involved in interoperating 
smoothly with the rest of the world than Aliens/CObjects, and what's 
left is very hard to do in a cross-dialect way.

So, having cross-dialect Aliens/CObjects is a nice step, but 
unfortunately it is still far from being a full solution.

Paolo

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Danny Chan
Am Samstag, 6. März 2010 09:19:24 schrieb Stéphane Ducasse:
> On Mar 6, 2010, at 9:01 AM, Danny Chan wrote:
> > Hi Torsten!
> >
> > I am the first to acknowledge that this is your project. And I am also
> > the first one to admit that my code is not great, being a beginner with
> > Smalltalk in the first place,
> 
> But this was great.
> I think that torsten was not negative

I did not think that this was the case. I just want to make explicit that I 
positively appreciate having someone with more experience rewrite my code. By 
seeing how someone else implements the ideas more cleanly I can only learn.

Danny

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Paolo Bonzini
On 03/06/2010 02:22 PM, Lawson English wrote:
> Does the CObject FFI allow you to do what F_script does and examine the
> entire object tree written in Cocoa? That would at least for Macs, give
> you a full blown GUI external to the Squeak desktop.

You _can_ write an Objective-C binding using CObject (as in, it's been 
done).  The painful part is converting NSArray <-> Array and NSString 
<-> String.

However, nice-looking bindings will always have a part written in C that 
will be VM-dependent, which is why I put this project last.  It is much 
less useful than it looks.

Paolo

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Paolo Bonzini
On 03/06/2010 02:22 PM, Lawson English wrote:
>
>  4) Build a continuous integration server using Seaside, Iliad or
>  AidaWeb.  Build an interface to version control systems (possibly
>  supporting both independent systems such as Monticello or
>  file-based such as svn/CVS/git) that can be used from Smalltalk
>  and integrate it with Smalllint code reports.  For a more
>  ambitious project, the server should be able to start a new image,
>  upgrade the package, run SUnit tests there and communicate back
>  the results---the time to upgrade the package should be minimized
>  of course!
>
>
> Are you aware of this two projects ? I don't know other dialects but in
> Pharo they work:
>
> http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834
> http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910

They seem to be very close to what I had in mind, in particular Hudson.

Paolo

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Lawson English
Mariano Martinez Peck wrote:
>
> 4) Build a continuous integration server using Seaside, Iliad or
> AidaWeb.  Build an interface to version control systems (possibly
> supporting both independent systems such as Monticello or
> file-based such as svn/CVS/git) that can be used from Smalltalk
> and integrate it with Smalllint code reports.  For a more
> ambitious project, the server should be able to start a new image,
> upgrade the package, run SUnit tests there and communicate back
> the results---the time to upgrade the package should be minimized
> of course!
>
>
> Are you aware of this two projects ? I don't know other dialects but 
> in Pharo they work:
>
> - http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834
> - 
> http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910
>
>  
>
>
> 5) Work on a cross-dialect foreign function call interface and
> implement it in at least two dialects.  Candidates include Alien
> and GNU Smalltalk's CObject (using existing implementation has the
> advantage of having to implement in only _one_ other dialect!).
>  Bonus points for implementing a C parser that would be able to
> construct bindings.  GNU Smalltalk already contains a C
> preprocessor implementation.
>
>
> Yes!!! And make it (optionally at least) not to block the complete VM 
> while a function is being called.
>
> Cheers
On the Mac version, having the power of Squeak combined with the power 
of F-Script would totally rule. Does the CObject FFI allow you to do 
what F_script does and examine the entire object tree written in Cocoa? 
That would at least for Macs, give you a full blown GUI external to the 
Squeak desktop.

Lawson

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Mariano Martinez Peck
> 4) Build a continuous integration server using Seaside, Iliad or AidaWeb.
>  Build an interface to version control systems (possibly supporting both
> independent systems such as Monticello or file-based such as svn/CVS/git)
> that can be used from Smalltalk and integrate it with Smalllint code
> reports.  For a more ambitious project, the server should be able to start a
> new image, upgrade the package, run SUnit tests there and communicate back
> the results---the time to upgrade the package should be minimized of course!
>

Are you aware of this two projects ? I don't know other dialects but in
Pharo they work:

- http://n4.nabble.com/Interim-build-server-td1296834.html#a1296834
-
http://n4.nabble.com/ANN-Hudson-continuous-integration-server-support-td1296910.html#a1296910



>
> 5) Work on a cross-dialect foreign function call interface and implement it
> in at least two dialects.  Candidates include Alien and GNU Smalltalk's
> CObject (using existing implementation has the advantage of having to
> implement in only _one_ other dialect!).  Bonus points for implementing a C
> parser that would be able to construct bindings.  GNU Smalltalk already
> contains a C preprocessor implementation.
>
>
Yes!!! And make it (optionally at least) not to block the complete VM while
a function is being called.

Cheers

Mariano
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] [Esug-list] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Paolo Bonzini
> We think that one of the most important reasons why we failed in 2009 is
> that Google was looking for bigger communities that Squeak. This is why
> this year we all go under the ESUG umbrella. We present ESUG as the
> mentor organization and we cover ALL open-source Smalltalk dialects, not
> only Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all
> invited to participate. Also cross platform projects like Seaside,
> AidaWeb, Magma, etc are welcome.

Here is a list of ideas from me, all more or less involving 
cross-dialect pollination.  These are based on my preferences, from most 
to least preferred

1) GNU Smalltalk includes a refactored version of Swazoo that supports 
SCGI and is also faster in general.  Start from there and backport the 
changes to Squeak/Pharo.  Use Seaside's Grease cross-dialect 
compatibility layer to get rid of (most of) the Sport dependency.

2) Convert existing cross-platform projects to use Grease.  Demonstrate 
them using two-three dialects (VW, Squeak, GST).  Discuss possible 
extensions to Grease and implement them.  Document Grease extension 
based on the formalism of the ANSI standard.

3) I agreed with the FSF to relicense GNU Smalltalk's file system 
classes under MIT license.  Port them to at least two other dialects 
(Squeak/Pharo count as one).  Think of cool ways to use them.  Possibly 
work out how to integrate them into Grease and make Seaside use them.

4) Build a continuous integration server using Seaside, Iliad or 
AidaWeb.  Build an interface to version control systems (possibly 
supporting both independent systems such as Monticello or file-based 
such as svn/CVS/git) that can be used from Smalltalk and integrate it 
with Smalllint code reports.  For a more ambitious project, the server 
should be able to start a new image, upgrade the package, run SUnit 
tests there and communicate back the results---the time to upgrade the 
package should be minimized of course!

5) Work on a cross-dialect foreign function call interface and implement 
it in at least two dialects.  Candidates include Alien and GNU 
Smalltalk's CObject (using existing implementation has the advantage of 
having to implement in only _one_ other dialect!).  Bonus points for 
implementing a C parser that would be able to construct bindings.  GNU 
Smalltalk already contains a C preprocessor implementation.

Paolo

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


[Pharo-project] Google Summer Of Code 2010 news!!!

2010-03-06 Thread Mariano Martinez Peck
Hi smalltalkers. I have been asked to be the admin of GSoC 2010. The backup
or second admin is Janko Mivšek. As you may know, Squeak has participated in
GSoC 2007, 2008 but failed (not accepted) in 2009. We are not sure if we
will succeed this year but we will try to do as much as possible.

We think that one of the most important reasons why we failed in 2009 is
that Google was looking for bigger communities that Squeak. This is why this
year we all go under the ESUG umbrella. We present ESUG as the mentor
organization and we cover ALL open-source Smalltalk dialects, not only
Squeak. Pharo, Smalltalk/X, GNU Smalltalk, Cuis..they are all invited to
participate. Also cross platform projects like Seaside, AidaWeb, Magma, etc
are welcome.


It is a Google program that support (money) students to work on different
open-source projects. Google doesn't talk or manage directly to the students
but trough "Mentoring Organisations". Those organizations have to apply to
GSoC. They have to give a lot of information, included a list of
ideas/projects. Each project has a description and a mentor. Then the
students apply for each project. If the organization gets selected by Google
they will tell you how many "slots" they give. Suppose they give 5 but we
have 20 projectsthen we vote and the most voted projects win. The
student has to do the project and the mentor has to help and guide him. The
mentor receives 500 USD and the student 4500USD.
For more information read: http://code.google.com/soc/


The most important thing is the deadlines we have. We started late so we are
very near to the first deadline which is 12/03/2010 (less than one week).
For that deadline we need to submit all the information of the mentor
organization (answering several questions) and give the list of
ideas/projects and the mentors of that.

We have created a webpage (Thanks Janko!!) where we will put all the
information. We will make this page public soon (we still need to review a
couple of things).
But for the moment we would REALLY appreciate if tell us your ideas. To do
this, just answer to this email. Then we will collect the information and
put in the website. For each idea you need:  a short title and a paragraph
(for the moment) explaining the idea.
After, we need that the people that are willing to be mentors start to apply
as mentors...please, consider yourself being mentor. Sometimes it is not
that difficult. I mean, don't be shy as sometimes being helpful, being aware
of the dates, answering emails, etc is more important than the Smalltalk
knoweldege. We can have a lot of ideas, but we need also mentors for that.
We even would need a "substitute" for each mentor...

Just as an example you can see the ideas of the previous years:
2007: http://wiki.squeak.org/squeak/5936
2008: http://wiki.squeak.org/squeak/6031
2009: http://wiki.squeak.org/squeak/6120

That's all for the moment.

Cheers

Mariano
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Re: [Pharo-project] Allow $- anywhere in binary selector

2010-03-06 Thread Stéphane Ducasse

On Mar 6, 2010, at 11:41 AM, Lukas Renggli wrote:

>>> - I can provide rewritten code for the complete core system that uses
>>> ambiguous constructs like 1...@-2.
>> 
>> Compiler recompileAll will transcript the ambiguous constructs already.
>> If you want, that would be useful to avoid spreading my initials
>> everywhere (I hate spreading, at least when I add no value).
> 
> I guess then just my initials are everywhere. Anyway, the point is
> that we fix all the places that need to be fixed. I have the RB
> rewrite script that does that already, I've posted a list with all the
> affected methods earlier on (there are about 30).

ok

Stef

> 
>> Personnally, I want the warning. It's so easy to get bitten by ^x/-2...
>> It would be good to have a Preference for the warning.
> 
> Yeah, maybe it is safer for casual Smalltalk programmers. I always put
> spaces before and after binary selectors anyway.
> 
> Lukas
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Allow $- anywhere in binary selector

2010-03-06 Thread Lukas Renggli
>> - I can provide rewritten code for the complete core system that uses
>> ambiguous constructs like 1...@-2.
>
> Compiler recompileAll will transcript the ambiguous constructs already.
> If you want, that would be useful to avoid spreading my initials
> everywhere (I hate spreading, at least when I add no value).

I guess then just my initials are everywhere. Anyway, the point is
that we fix all the places that need to be fixed. I have the RB
rewrite script that does that already, I've posted a list with all the
affected methods earlier on (there are about 30).

> Personnally, I want the warning. It's so easy to get bitten by ^x/-2...
> It would be good to have a Preference for the warning.

Yeah, maybe it is safer for casual Smalltalk programmers. I always put
spaces before and after binary selectors anyway.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Allow $- anywhere in binary selector

2010-03-06 Thread Nicolas Cellier
2010/3/6 Lukas Renggli :
>> Nicolas published a version for pharo and it would be really cool if you 
>> could help me
>>        http://code.google.com/p/pharo/issues/detail?id=2115
>
> What should I do?
>
> - I can update the RB so that it works the same way.
>

Yes

> - I can provide rewritten code for the complete core system that uses
> ambiguous constructs like 1...@-2.
>

Compiler recompileAll will transcript the ambiguous constructs already.
If you want, that would be useful to avoid spreading my initials
everywhere (I hate spreading, at least when I add no value).

> For the compile changes themselves I wouldn't throw a warning, not
> even in interactive mode. Also I wouldn't add a setting, that just
> causes troubles in many years ahead.
>

Agree about Preferences for accepting incompatible syntax : it is poisonous.
This preference would be usefull only to load old packages, but risk
to be abused to write non conforming code.

Personnally, I want the warning. It's so easy to get bitten by ^x/-2...
It would be good to have a Preference for the warning.

Nicolas

> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Allow $- anywhere in binary selector

2010-03-06 Thread Lukas Renggli
> Nicolas published a version for pharo and it would be really cool if you 
> could help me
>        http://code.google.com/p/pharo/issues/detail?id=2115

What should I do?

- I can update the RB so that it works the same way.

- I can provide rewritten code for the complete core system that uses
ambiguous constructs like 1...@-2.

For the compile changes themselves I wouldn't throw a warning, not
even in interactive mode. Also I wouldn't add a setting, that just
causes troubles in many years ahead.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


[Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Torsten Bergmann
Hi Danny,

> I am the first to acknowledge that this is your project.

No, no - it is not mine or yours. It is "Pharo Help" and it is 
"our" project - that's why the repo is open and the code is MIT!

Didnt you see the ;) behind my statements! 

>And I am also the first one to admit that my code is not great

How do you measure the greatness of code? ;)

Dont by shy! You idea and code is a great addition since we can
and will definitely use it. Anything I've said is that I want
to restructure it to align it with my design ideas
(which I was not yet able to fully communicate since I'm in the 
midst of changing the original design)

>being a beginner with Smalltalk in the first place, not being a software 
>>developer secondly 

Sometimes developers are already too "computer focused" in thinking.
So we need people with a different background and fresh ideas.
Welcome to Smalltalk!

>and playing with software only in my spare time (which will be 
>certainly much less in the future, because I just got a brand new >daughter). 

Excellent! I have two daughters myself (2 years and a 7 month baby).

>So please see my contributions more as sketches of the functionality that 
>might be nice to have in a help system, rather than a real implementation

As I said - it will definitely in the next version in one way or the other.

Thanks
T.








-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


[Pharo-project] Allow $- anywhere in binary selector

2010-03-06 Thread stephane ducasse
Lukas and others 

Nicolas published a version for pharo and it would be really cool if you could 
help me 
http://code.google.com/p/pharo/issues/detail?id=2115

Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Stéphane Ducasse

On Mar 6, 2010, at 9:01 AM, Danny Chan wrote:

> 
> Hi Torsten!
> 
> I am the first to acknowledge that this is your project. And I am also the 
> first 
> one to admit that my code is not great, being a beginner with Smalltalk in 
> the 
> first place,

But this was great.
I think that torsten was not negative

> not being a software developer secondly (I develop optical systems 
> in my day job), and playing with software only in my spare time (which will 
> be 
> certainly much less in the future, because I just got a brand new daughter). 

Excellent!
It depends if it lets u sleep!

> So please see my contributions more as sketches of the functionality that 
> might be nice to have in a help system, rather than a real implementation. I 
> am completely happy if people get a rough idea of what might be desireable, 
> and then throw away the whole mess I've made and do it right! So please, 
> scrap 
> the stuff and implement it cleanly, because only by seeing what you are doing 
> with the code I am learning.

Excellent!

Thanks again for the stamp :)
> 
> Cheers, Danny
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Stéphane Ducasse

On Mar 6, 2010, at 1:27 AM, Torsten Bergmann wrote:

> Stef wrote:
>> I noticed it :)
> 
> So I renamed the topic ;)
> 
>> we are not in rush.
> 
> Good. I trimmed the model down this evening to just one class
> and even the help browser is now much more flexible (already 
> displaying static and dynamic help)
> 
>> But I'm pragmatic.
>>  - how to we fill up the help
> 
> With the new simpler model you will be able to
> easily transform various sources ... for instance I think on
> even getting RSS feeds, IRC, list archive ... included 
> by loading additional packages. I'm sure we will get more ideas
> once this all works.
> 
>> For the UML I would like to have a simple sccripting descriptoin so that we 
>> can >define it.
> 
> Do you know yuml.me?

Yes I do not want to rely on the web for UML class.
I want something inside.

Stef

> http://yuml.me/diagram/class/class/[Collection],[Collection]-[CharacterSet]
> 
> The interesting thing is that we can even built this into the help browser
> today using HTTP and images - but one has to be online.
> 
> However ... first I want to get the right infrastructure. More coming soon.
> 
> If one wants to help: create a good HTML viewer based on the reworked
> Scamper (see http://www.squeaksource.com/LaurentLSandbox.html). 
> 
> Bye
> T.
> 
> 
> 
> 
> -- 
> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
> 
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Re: [Pharo-project] Pharo help (was About danny help :)

2010-03-06 Thread Danny Chan

Hi Torsten!

I am the first to acknowledge that this is your project. And I am also the 
first 
one to admit that my code is not great, being a beginner with Smalltalk in the 
first place, not being a software developer secondly (I develop optical systems 
in my day job), and playing with software only in my spare time (which will be 
certainly much less in the future, because I just got a brand new daughter). 
So please see my contributions more as sketches of the functionality that 
might be nice to have in a help system, rather than a real implementation. I 
am completely happy if people get a rough idea of what might be desireable, 
and then throw away the whole mess I've made and do it right! So please, scrap 
the stuff and implement it cleanly, because only by seeing what you are doing 
with the code I am learning.

Cheers, Danny

___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project