April 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Setup package fixes

by Sean P. DeNigris

I sent some fixes to the package owner, but also posted a link to the mcz file http://seandenigris.com/files/Setup-SeanDeNigris.47.mcz here , in case anyone wants it. * Fix - Setup>>installDevelopment - changed from Installer (which is not pre-installed in Pharo 1.0) to Gopher. * Fix - Setup>>installSpecificUser - Changed "Author initials" (depreciated in Pharo 1.0) to "author fullName". - changed all author initials to full names, except jre because I didn't know what it stood for. I tested it against Pharo-Core 1.0 & PharoCore-1.1-11312-UNSTABLE. I tried to port it to Squeak 4.1, but got various errors, so I backed out the changes. But if you are interested, I can send them to you. Sean -- View this message in context: http://n4.nabble.com/Setup-package-fixes-tp2015309p2015309.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 19, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.0 released!

by Stephen Taylor

Henrik Johansen wrote: > Gotta love reddit... [...] > - "I don't know what Smalltalk is, and the site doesn't tell me, not even the about page!" That one I think is legitimate - and not just for Pharo but for almost every Open Source project out there. I think every project's home page should keep first time in visitors in mind. (My very least favourite thing for the first page of a site is to see the project commit log - talk about unwelcoming!). And to say something positive - Pharo 1.0 looks great - solid and serious and workable. A couple of my co-workers have called my bluff and asked for a Smalltalk tutorial, and I'll be happy to show them Pharo. > Henry Steve

April 18, 2010

Re: [Pharo-project] [Vm-dev] Re: we need help for rome

by Bert Freudenberg

On 18.04.2010, at 20:14, stephane ducasse wrote: > > > Thanks Bert > >> >> I think only the first 4 inst vars are actually used by the plugin: >> >> http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… >> #define CanvasHandleIndex 0 >> #define CanvasTargetIndex 1 >> #define CanvasFlagsIndex 2 >> #define CanvasStrokeColorIndex 3 >> #define CanvasInstSize 8 > > how did you get that information? from the image side or C code? > Because I tried to see but unsure. It's in the C code I linked above. I just reordered it for better readability. >> So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). > > Now I understand why alain could remove the instance variable when cleaning the image side. > >> The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. > > > I browsed a bit the C code and I'm learning so may be my questions are not clever, but > > - do we need the pango primitives for ROME? > Apparently Pango may use Cairo for fonts rendering but do Rome needs that? > So is it simpler to use fonts via pango than cairo. Pango provides word/paragraph layout. Many non-latin scripts (e.g. Devanagari) require "glyph shaping", there is no one-to-one mapping between Unicode characters and glyphs rendered in context. Pango can do that. I'm not aware of any other renderer in Squeak that would support this (Yoshiki added it for OLPC). Well, maybe the Unicode plugin from Scratch could do it too, not sure. > - then what about FormInstSize? > > (interpreterProxy->slotSizeOf(formOop)) < FormInstSize > does it mean Same thing. The instance variables actually used by the plugin should be hard coded. Otherwise the same would happen as in Sophie - some inst vars were added to the Canvas, so the inst size compiled into the plugin became larger than necessary. Btw, by now you probably have guessed that a workaround for the Mac issue would be to add 5 dummy inst vars to RomePluginCanvas just to make the plugin happy. > - the primitives we have access to are listed by > void* RomePlugin_exports[][3] = { Right. > - how do we know that the plugin is somehow in sync with Cairo "latest" version? It doesn't need to be "in sync". But maybe I do not understand the question. - Bert - > Stef > >> >> - Bert - >> >> On 18.04.2010, at 18:45, StÃ©phane Ducasse wrote: >>> >>> John >>> >>> how can I know the order and the iv that are used by the plugin? >>> >>> Stef >>> >>> On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: >>> >>>> (a) In Sophie >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' >>>> classVariableNames: 'CachedTarget FlagFill FlagStro >>>> >>>> (b) In Pharo >>>> >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' >>>> classVariableNames: 'FlagFill FlagStroke Registry' >>>> poolDictionaries: '' >>>> category: 'Rome-PluginCanvas' >>>> >>>> Comment warning: >>>> >>>> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! >>>> >>>> >>>> So in the plugin we have... >>>> >>>> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize) >>>> fail(). >>>> >>>> >>>> where CanvasInstSize is 13 >>>> >>>> but as you see in (b) the number of instance slots for the canvas Oops is 8. >>>> >>>> 8 < 13, oops you fail. >>>> >>>> So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt >>>> go? On purpose gone, refactored, old code. etc.... >>>> >>>> >>>> On 2010-04-16, at 1:37 PM, StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: >>>>> >>>>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. >>>>> >>>>> I like to hear that because I feel less idiot. :) >> >

April 18, 2010

Re: [Pharo-project] [Vm-dev] Re: we need help for rome

by John M McIntosh

Well hey I'm just the guy tapping the compile button, er no support agreement here... Likely the original plugin code came via MCHttpRepository location: 'http://source.impara.de/Rome' user: '' password: '' If someone wants to make the required fixes to the plugin code, and the smalltalk code I *think* I can build a new plugin.. Likely this won't affect Sophie users (if any) because that's a one click app. However this means an update to the mac vm's and other platforms in order to ensure the smalltalk class in a Pharo image matches expectations. On 2010-04-18, at 10:45 AM, Bert Freudenberg wrote: > > I think only the first 4 inst vars are actually used by the plugin: > > http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… > #define CanvasHandleIndex 0 > #define CanvasTargetIndex 1 > #define CanvasFlagsIndex 2 > #define CanvasStrokeColorIndex 3 > #define CanvasInstSize 8 > > So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). > > The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. > > - Bert - > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 18, 2010

Re: [Pharo-project] Iliad 0.8 released!

by Nicolas Petton

Le dimanche 18 avril 2010 Ã 19:25 +0100, Julian Fitzell a Ã©crit : > 2010/4/18 Nicolas Petton <petton.nicolas(a)gmail.com> > Now I'm not really happy with the codec stuff, as from a GNU > Smalltalker > point of view it seems too Squeak/Pharo oriented, but I can > leave with > that for now. > > To be honest, I'm not totally happy with that part either. :) It's > good enough for now but reworking the encoding stuff is on my > (personal, anyway) list for Seaside 3.1. Why do you keep Grease into Seaside's repository? Couldn't it have its own repository and roadmap? Nicolas

April 18, 2010

Re: [Pharo-project] Iliad 0.8 released!

by Julian Fitzell

2010/4/18 Nicolas Petton <petton.nicolas(a)gmail.com> > Now I'm not really happy with the codec stuff, as from a GNU Smalltalker > point of view it seems too Squeak/Pharo oriented, but I can leave with > that for now. > To be honest, I'm not totally happy with that part either. :) It's good enough for now but reworking the encoding stuff is on my (personal, anyway) list for Seaside 3.1. Julian

April 18, 2010

[Pharo-project] Fwd: [Vm-dev] Re: we need help for rome

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: April 18, 2010 8:15:05 PM GMT+02:00 > To: stephane.ducasse(a)gmail.com > Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: April 18, 2010 8:14:58 PM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Vm-dev] Re: [Pharo-project] we need help for rome > > > Thanks Bert > >> >> I think only the first 4 inst vars are actually used by the plugin: >> >> http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… >> #define CanvasHandleIndex 0 >> #define CanvasTargetIndex 1 >> #define CanvasFlagsIndex 2 >> #define CanvasStrokeColorIndex 3 >> #define CanvasInstSize 8 > > how did you get that information? from the image side or C code? > Because I tried to see but unsure. > >> >> So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). > > Now I understand why alain could remove the instance variable when cleaning the image side. > > >> The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. > > > I browsed a bit the C code and I'm learning so may be my questions are not clever, but > > - do we need the pango primitives for ROME? > Apparently Pango may use Cairo for fonts rendering but do Rome needs that? > So is it simpler to use fonts via pango than cairo. > > - then what about FormInstSize? > > (interpreterProxy->slotSizeOf(formOop)) < FormInstSize > does it mean > > - the primitives we have access to are listed by > void* RomePlugin_exports[][3] = { > > - how do we know that the plugin is somehow in sync with Cairo "latest" version? > > Stef > >> >> - Bert - >> >> On 18.04.2010, at 18:45, StÃ©phane Ducasse wrote: >>> >>> John >>> >>> how can I know the order and the iv that are used by the plugin? >>> >>> Stef >>> >>> On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: >>> >>>> (a) In Sophie >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' >>>> classVariableNames: 'CachedTarget FlagFill FlagStro >>>> >>>> (b) In Pharo >>>> >>>> RomeCanvas subclass: #RomePluginCanvas >>>> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' >>>> classVariableNames: 'FlagFill FlagStroke Registry' >>>> poolDictionaries: '' >>>> category: 'Rome-PluginCanvas' >>>> >>>> Comment warning: >>>> >>>> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! >>>> >>>> >>>> So in the plugin we have... >>>> >>>> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize) >>>> fail(). >>>> >>>> >>>> where CanvasInstSize is 13 >>>> >>>> but as you see in (b) the number of instance slots for the canvas Oops is 8. >>>> >>>> 8 < 13, oops you fail. >>>> >>>> So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt >>>> go? On purpose gone, refactored, old code. etc.... >>>> >>>> >>>> On 2010-04-16, at 1:37 PM, StÃ©phane Ducasse wrote: >>>> >>>>> >>>>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: >>>>> >>>>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. >>>>> >>>>> I like to hear that because I feel less idiot. :) >> > > > >

April 18, 2010

Re: [Pharo-project] Help on collaborator Active book

by StÃ©phane Ducasse

this is really cool to see this collaborative space taking shape. I should start to write other chapters directly there too > Fixed. > > Doru > > > On 18 Apr 2010, at 19:15, Lukas Renggli wrote: > >>> cheers Lukas, can you check how it has rendered, i am not sure the >>> copy/paste has quite worked? >> >> Looks good, except for the part on keywords. Probably the mail messed >> up some line wrappings. >> >> Lukas >> >> >> >> >>> >>> Mike >>> >>> On Sun, Apr 18, 2010 at 10:57 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> yes i was going to copy it into the new help section. Can someone with >>>>> access to book.seaside.st send me the original markup? or tell me how >>>>> I can view the pier source. I have added a link for now. >>>> >>>> +value:toc+ >>>> >>>> !Parts, Chapters, Sections, Subsections >>>> >>>> Do not use the heading markup !, it cannot be properly converted to >>>> Latex. Instead add a new structure for every section using the ==Add== >>>> command. Name the section according to their latex label, only use >>>> lowercase characters and no spaces. This is the name that will appear >>>> in the URL. For the title capitalize the individual words. >>>> >>>> Chapters, sections and subsections are displayed in the order they are >>>> created. They can be rearranged using the ==Order== command. >>>> >>>> !Figures >>>> >>>> To embed a figure create a link of the form >>>> >>>> =+foo.png|width=100%+ >>>> >>>> The line embeds the figure and sets the width of the image. For the >>>> width use a percentage between 50% and 100%. Only upload PNG files >>>> without transparency, no JPEG or GIF files. Do not upload files that >>>> have spaces in their name. As the name property use the name of the >>>> file you upload. Edit the title property, it will become the caption >>>> of the image and show up in the index of figures. >>>> >>>> If the figure does not exist yet, it will show as a red link. Clicking >>>> on it allows you to create it. Chose "Book Figure" as the structure >>>> type to create. Then on the next page edit the title (caption) and >>>> upload the image. >>>> >>>> !Keyword Index >>>> To add a keyword to the index use ==\+index:WAComponent\+==. To add a >>>> two level keyword use the syntax >>>> ==\+index:WAComponent!renderContentOn:\+==. Note that this markup does >>>> not generate any output. Preferably put it at the beginning of the >>>> paragraph. >>>> >>>> !Source Code >>>> For inlined source code use the syntax ==\==100 factorial\== ==. For >>>> blocks of code that should be highlighted using the Smalltalk parser >>>> begin each line with == \== ==. Use 4 spaces to indent the code, no >>>> tabs. >>>> >>>> ==Integer>>factorial >>>> == ^ self < 2 >>>> == ifTrue: [ 1 ] >>>> == ifFalse: [ self * (self - 1) factorial ] >>>> >>>> To have non highlighted code begin each line with a single =====. >>>> >>>> =squeak -headless seaside.image >>>> >>>> !References >>>> >>>> To create references to chapters, sections or figures use the normal >>>> link-syntax but prepend it with ==ref:==, for example: >>>> >>>> =*ref:foo.png* >>>> =*ref:../components* >>>> >>>> @here >>>> This will create a link of the form *Form 123>.@here* and *Section 4>.@here*. >>>> >>>> !Paragraph >>>> Avoid unnecessary line breaks in paragraphs. Don't use wrapped text, >>>> that is clumsy and almost impossible to edit afterwards from the web >>>> browser. In TextMate use the command ''Unwrap Paragraph >>>> (Ctrl\+Alt\+Q)'' to properly format the paragraph before pasting into >>>> Pier. >>>> >>>> Use the syntax ==\@@important This is the paragraph text.== to >>>> annotate a paragraph. >>>> >>>> @@important This is an ==\@@important== paragraph. >>>> >>>> @@blockquote This is a ==\@@blockquote== paragraph. >>>> >>>> @@note This is a ==\@@note== paragraph. >>>> >>>> @@advanced This is an ==\@@advanced== paragraph. >>>> >>>> @@todo This is a ==\@@todo== paragraph. >>>> >>>> !Navigation >>>> | j | Previous Page >>>> | k | Next Page >>>> | p | Parent Page >>>> | i | Table of Contents >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 18, 2010

Re: [Pharo-project] we need help for rome

by Bert Freudenberg

I think only the first 4 inst vars are actually used by the plugin: http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/… #define CanvasHandleIndex 0 #define CanvasTargetIndex 1 #define CanvasFlagsIndex 2 #define CanvasStrokeColorIndex 3 #define CanvasInstSize 8 So on Linux, Rome does use the "right" size. John appears to have used a Sophie image to generate his Plugin, which makes this fail (though I could not find his Rome plugin in the Mac OS platform code so can't verify that theory). The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore. - Bert - On 18.04.2010, at 18:45, StÃ©phane Ducasse wrote: > > John > > how can I know the order and the iv that are used by the plugin? > > Stef > > On Apr 17, 2010, at 4:09 AM, John M McIntosh wrote: > >> (a) In Sophie >> RomeCanvas subclass: #RomePluginCanvas >> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt drawRunPositions drawRunGlyph drawRunPointY' >> classVariableNames: 'CachedTarget FlagFill FlagStro >> >> (b) In Pharo >> >> RomeCanvas subclass: #RomePluginCanvas >> instanceVariableNames: 'handle target flags strokeColor stack font fontSize fontMatrix' >> classVariableNames: 'FlagFill FlagStroke Registry' >> poolDictionaries: '' >> category: 'Rome-PluginCanvas' >> >> Comment warning: >> >> INST VAR ORDER IS KNOWN TO PLUGIN! DO NOT REARRANGE! >> >> >> So in the plugin we have... >> >> if (interpreterProxy->slotSizeOf(canvasOop)) < CanvasInstSize) >> fail(). >> >> >> where CanvasInstSize is 13 >> >> but as you see in (b) the number of instance slots for the canvas Oops is 8. >> >> 8 < 13, oops you fail. >> >> So where did the instance vars currentFillColor currentBackColor glyphAccuracy cachedGlyphBlt cachedClearBlt >> go? On purpose gone, refactored, old code. etc.... >> >> >> On 2010-04-16, at 1:37 PM, StÃ©phane Ducasse wrote: >> >>> >>> On Apr 16, 2010, at 10:30 PM, John McIntosh wrote: >>> >>>> Well I'm just as puzzled as you since the primitive gets executed and you are using the same binary that was shipped with Sophie years back. >>> >>> I like to hear that because I feel less idiot. :)

April 18, 2010

Re: [Pharo-project] Help on collaborator Active book

by Tudor Girba

Fixed. Doru On 18 Apr 2010, at 19:15, Lukas Renggli wrote: >> cheers Lukas, can you check how it has rendered, i am not sure the >> copy/paste has quite worked? > > Looks good, except for the part on keywords. Probably the mail messed > up some line wrappings. > > Lukas > > > > >> >> Mike >> >> On Sun, Apr 18, 2010 at 10:57 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >>>> yes i was going to copy it into the new help section. Can someone >>>> with >>>> access to book.seaside.st send me the original markup? or tell me >>>> how >>>> I can view the pier source. I have added a link for now. >>> >>> +value:toc+ >>> >>> !Parts, Chapters, Sections, Subsections >>> >>> Do not use the heading markup !, it cannot be properly converted to >>> Latex. Instead add a new structure for every section using the >>> ==Add== >>> command. Name the section according to their latex label, only use >>> lowercase characters and no spaces. This is the name that will >>> appear >>> in the URL. For the title capitalize the individual words. >>> >>> Chapters, sections and subsections are displayed in the order they >>> are >>> created. They can be rearranged using the ==Order== command. >>> >>> !Figures >>> >>> To embed a figure create a link of the form >>> >>> =+foo.png|width=100%+ >>> >>> The line embeds the figure and sets the width of the image. For the >>> width use a percentage between 50% and 100%. Only upload PNG files >>> without transparency, no JPEG or GIF files. Do not upload files that >>> have spaces in their name. As the name property use the name of the >>> file you upload. Edit the title property, it will become the caption >>> of the image and show up in the index of figures. >>> >>> If the figure does not exist yet, it will show as a red link. >>> Clicking >>> on it allows you to create it. Chose "Book Figure" as the structure >>> type to create. Then on the next page edit the title (caption) and >>> upload the image. >>> >>> !Keyword Index >>> To add a keyword to the index use ==\+index:WAComponent\+==. To >>> add a >>> two level keyword use the syntax >>> ==\+index:WAComponent!renderContentOn:\+==. Note that this markup >>> does >>> not generate any output. Preferably put it at the beginning of the >>> paragraph. >>> >>> !Source Code >>> For inlined source code use the syntax ==\==100 factorial\== ==. For >>> blocks of code that should be highlighted using the Smalltalk parser >>> begin each line with == \== ==. Use 4 spaces to indent the code, no >>> tabs. >>> >>> ==Integer>>factorial >>> == ^ self < 2 >>> == ifTrue: [ 1 ] >>> == ifFalse: [ self * (self - 1) factorial ] >>> >>> To have non highlighted code begin each line with a single =====. >>> >>> =squeak -headless seaside.image >>> >>> !References >>> >>> To create references to chapters, sections or figures use the normal >>> link-syntax but prepend it with ==ref:==, for example: >>> >>> =*ref:foo.png* >>> =*ref:../components* >>> >>> @here >>> This will create a link of the form *Form 123>.@here* and *Section >>> 4>.@here*. >>> >>> !Paragraph >>> Avoid unnecessary line breaks in paragraphs. Don't use wrapped text, >>> that is clumsy and almost impossible to edit afterwards from the web >>> browser. In TextMate use the command ''Unwrap Paragraph >>> (Ctrl\+Alt\+Q)'' to properly format the paragraph before pasting >>> into >>> Pier. >>> >>> Use the syntax ==\@@important This is the paragraph text.== to >>> annotate a paragraph. >>> >>> @@important This is an ==\@@important== paragraph. >>> >>> @@blockquote This is a ==\@@blockquote== paragraph. >>> >>> @@note This is a ==\@@note== paragraph. >>> >>> @@advanced This is an ==\@@advanced== paragraph. >>> >>> @@todo This is a ==\@@todo== paragraph. >>> >>> !Navigation >>> | j | Previous Page >>> | k | Next Page >>> | p | Parent Page >>> | i | Table of Contents >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

April 18, 2010