November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Git API for Pharo

by StÃ©phane Ducasse

On Nov 7, 2012, at 9:08 AM, roberto.minelli(a)usi.ch wrote: > Hello, > > I need to access a Git repository programmatically from Pharo. > > Is there any API to work with Git working copies, access and manipulate repositories programmatically? if you find it we need that too :) Stef > > In short I need to checkout each revision of a project and extract some meta-data from each revision. > > Thanks in advance, > Roberto

Nov. 7, 2012

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by Camillo Bruni

Awesome!! BTW how do you deal with text formatting? For NativeBoost we used MarkDown to add sourceCode / method / class and section links to the documentation. With the formatting and the webserver the documentation would be almost perfect in my eyes! On 2012-11-06, at 23:13, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > a little story: > > As you may know I wrote the current "Pharo help" implementation which > you can access from the Help menu or via > > HelpBrowser open > > I'm still not satisfied with it. Some projects like NativeBoost, > Metacello and others already provide an appropriate help package - but > still beginners help and documentation is not where I would like to see it. > > The HelpBrowser is only usable within the image and other nice docu (blog > posts, videos, ...) for Pharo is available online. You have to know > about these pages after downloading Pharo to find the tips and tricks > and nice features of the Smalltalk world. > > There is also no central "docu" point for someone who just downloaded > Pharo and want a "Quick start". Also I dislike that we are limited with > the in-image presentation style (text only) and that content is not > visible to Google, Bing, etc. > > That made me think about web/HTML/Internet like documentation again > and the image as the central place beginners have downloaded already. > > After many years of private research I now noticed that HTML is > nothing more than a structured String - so I started coding... :) > > Packaging Seaside with the default Pharo image to serve help content > would be overkill - but there is always a leaner way. > Since Pharo 2.0 we have Zinc HTTP components within the image > (thanks Sven!) and I played a little bit with it. It is really easy > to setup/startup a webserver from Smalltalk now. > > So I wrote a basic "HelpServer" and wrapped the nice "twitter bootstrap" > library. Code may be ugly and require some refactoring ... but it is > currently more a prove of concept. > > Attached is a screenshot of the result running in a webbrowser. > > > What is it: the idea is that we server the documentation from within the > image but use the local webbrowser to display it. Since we soon integrate NativeBoost in Pharo 2.0 it is also easy to open the browser as soon as "Help" is requested from a menu. > > Serving for the web would also mean we could easily setup an image > online that displays the docu online for indexing by search engines etc. > > Where is the code: > > http://ss3.gemstone.com/ss/PharoOnlineHelp.html (Read/Write) > > If you want to play with it yourself then start a Pharo 2.0 image, go to > "Tools" -> "ConfigurationBrowser", select "PharoOnlineHelp" and select > "Install configuration (stable version)" from the context menu. > > After that evaluate > > HelpServer start > > and point your browser to http://localhost:8080 > > > If you like scripting you can also evaluate in a Pharo 2.0 image: > > -------------------------------------------------------------------------------- > Gofer it > squeaksource3: 'PharoOnlineHelp'; > package: 'ConfigurationOfPharoOnlineHelp'; > load. > > ((Smalltalk at: #ConfigurationOfPharoOnlineHelp) project version: #stable) load. > (Smalltalk at: #HelpServer) start > -------------------------------------------------------------------------------- > > > Next steps: > =========== > > 1. Lets discuss how we want to fill the "API help" section. I know that > there once was a project that generated static API help > (http://magaloma.seasidehosting.st) but we can now directly serve > from the live image. > > My current implementation allows to navigate from classes to > subclasses and superclasses - just to give you an idea. Maybe we > want to display only class comments or provide a real Smalltalk > browser within the webbrowser (similar to http://www.Amber-lang.net) > > 2. The section "Intro" is only a mock. I would like to see that people > can find short "Quick start" like tutorials here to start with > basic things like Smalltalk, Metacello, ... > > Maybe we can integrate a live and running ProfStef similar to > http://amber-lang.net/learn.html that is adopted to Pharo. > > 3. Lets discuss how we want to describe the content "in-image" > for "serving on the web". Maybe with a "Markup to HTML translator" > - or a "WikiStyle to HTML" like help > > My wish to Santa would be that Pharo 2.0 comes with a better and > nicer out-of-the-box documentation. For each package/project we should > have a common way to define/load/browse docu and tutorials so people > can just load and quick start without much hazzle. > > The code repo is open for read and write - I would appreciate > comments, code contributions, help/tutorial content and ideas. > > Thanks > Torsten > <onlinehelp.png>

Nov. 7, 2012

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by StÃ©phane Ducasse

this is cool. No time to fully read now but later for sure. I would like to see how we can integrate the book chapters. This is why we brainstormed with damien c to see how we can use Pier format as a core format for all the doc and so that we can generate the book (like for the seaside book). Stef On Nov 6, 2012, at 11:13 PM, Torsten Bergmann wrote: > Hi, > > a little story: > > As you may know I wrote the current "Pharo help" implementation which > you can access from the Help menu or via > > HelpBrowser open > > I'm still not satisfied with it. Some projects like NativeBoost, > Metacello and others already provide an appropriate help package - but > still beginners help and documentation is not where I would like to see it. > > The HelpBrowser is only usable within the image and other nice docu (blog > posts, videos, ...) for Pharo is available online. You have to know > about these pages after downloading Pharo to find the tips and tricks > and nice features of the Smalltalk world. > > There is also no central "docu" point for someone who just downloaded > Pharo and want a "Quick start". Also I dislike that we are limited with > the in-image presentation style (text only) and that content is not > visible to Google, Bing, etc. > > That made me think about web/HTML/Internet like documentation again > and the image as the central place beginners have downloaded already. > > After many years of private research I now noticed that HTML is > nothing more than a structured String - so I started coding... :) > > Packaging Seaside with the default Pharo image to serve help content > would be overkill - but there is always a leaner way. > Since Pharo 2.0 we have Zinc HTTP components within the image > (thanks Sven!) and I played a little bit with it. It is really easy > to setup/startup a webserver from Smalltalk now. > > So I wrote a basic "HelpServer" and wrapped the nice "twitter bootstrap" > library. Code may be ugly and require some refactoring ... but it is > currently more a prove of concept. > > Attached is a screenshot of the result running in a webbrowser. > > > What is it: the idea is that we server the documentation from within the > image but use the local webbrowser to display it. Since we soon integrate NativeBoost in Pharo 2.0 it is also easy to open the browser as soon as "Help" is requested from a menu. > > Serving for the web would also mean we could easily setup an image > online that displays the docu online for indexing by search engines etc. > > Where is the code: > > http://ss3.gemstone.com/ss/PharoOnlineHelp.html (Read/Write) > > If you want to play with it yourself then start a Pharo 2.0 image, go to > "Tools" -> "ConfigurationBrowser", select "PharoOnlineHelp" and select > "Install configuration (stable version)" from the context menu. > > After that evaluate > > HelpServer start > > and point your browser to http://localhost:8080 > > > If you like scripting you can also evaluate in a Pharo 2.0 image: > > -------------------------------------------------------------------------------- > Gofer it > squeaksource3: 'PharoOnlineHelp'; > package: 'ConfigurationOfPharoOnlineHelp'; > load. > > ((Smalltalk at: #ConfigurationOfPharoOnlineHelp) project version: #stable) load. > (Smalltalk at: #HelpServer) start > -------------------------------------------------------------------------------- > > > Next steps: > =========== > > 1. Lets discuss how we want to fill the "API help" section. I know that > there once was a project that generated static API help > (http://magaloma.seasidehosting.st) but we can now directly serve > from the live image. > > My current implementation allows to navigate from classes to > subclasses and superclasses - just to give you an idea. Maybe we > want to display only class comments or provide a real Smalltalk > browser within the webbrowser (similar to http://www.Amber-lang.net) > > 2. The section "Intro" is only a mock. I would like to see that people > can find short "Quick start" like tutorials here to start with > basic things like Smalltalk, Metacello, ... > > Maybe we can integrate a live and running ProfStef similar to > http://amber-lang.net/learn.html that is adopted to Pharo. > > 3. Lets discuss how we want to describe the content "in-image" > for "serving on the web". Maybe with a "Markup to HTML translator" > - or a "WikiStyle to HTML" like help > > My wish to Santa would be that Pharo 2.0 comes with a better and > nicer out-of-the-box documentation. For each package/project we should > have a common way to define/load/browse docu and tutorials so people > can just load and quick start without much hazzle. > > The code repo is open for read and write - I would appreciate > comments, code contributions, help/tutorial content and ideas. > > Thanks > Torsten > <onlinehelp.png>

Nov. 7, 2012

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by StÃ©phane Ducasse

On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote: > On 6 November 2012 17:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> This is clearly something to add to the documentation of NativeBoost. >> Igor can you do it? > > I already have a description of memory management API for NB in docs. > And telling how manage external memory is... ahem.. not really fits into docs :) > Maybe a tutor or something. think not technical but user! Id o not give a shit if what helps me is called a doc or a tutorial. I care that it helps me fixing my problem. And what I see is that the example of Max is a nice example of a recurring problem people face. Stef > > > > -- > Best regards, > Igor Stasenko. >

Nov. 7, 2012

Re: [Pharo-project] [Pharo-users] Pharo consortium agreement

by Damien Cassou

On Tue, Nov 6, 2012 at 6:09 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > These are part of the Pharo User Association. This is ready, too and will > be announced the next days. Is the Association a member of the Consortium? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 7, 2012

[Pharo-project] Git API for Pharo

by roberto.minelli＠usi.ch

Hello, I need to access a Git repository programmatically from Pharo. Is there any API to work with Git working copies, access and manipulate repositories programmatically? In short I need to checkout each revision of a project and extract some meta-data from each revision. Thanks in advance, Roberto

Nov. 7, 2012

Re: [Pharo-project] [squeak-dev] Re: now that squeaksource is back...

by Paul DeBruicker

Frank Shearar-3 wrote > On 6 November 2012 16:55, Mariano Martinez Peck < > marianopeck@ > > wrote: >> >>> > >>> > That's already there. >>> > Metacello can say: get this package from this list of possible >>> > repositories. >>> > Problem is that most of configurations are not aware of that. >>> > >>> > spec repositories: [ >>> > spec repository: 'primary'. >>> > spec repository: 'secundary'. >>> > spec repository: 'etc...' ] >>> >>> That's not what I meant. I want the author to say "this piece of >>> software contains these parts, and these are the canonical locations", >>> and the user should be able to completely override those locations. >>> >> >> #repositoryOverrides: >> >> self whateverVersion repositoryOverrides: (self whateverRepo); load > > I have actually tried to do these things. repositoryOverrides: is > _insufficient_. It doesn't protect you from a transitive dependency's > repository not being available. > > frank I created a solution that may do what you want on Pharo or be a start for what you have in mind here: http://code.google.com/p/metacello/issues/detail?id=182 The code in that changeset detects whether Squeaksource is down when loading a project and then load it and its dependencies from the Chilean mirror if Squeaksource is down. It only replaces the squeaksource repos with chilean repos during each run of the loading process rather than editing the project's configs. It does that for the project you want to load and all its dependent projects and packages. And their dependenices. It allowed me to load Seaside 3.0.7 into a fresh Pharo 1.4 image from Chile when squeaksource was down yesterday. The issue I ran into on Squeak 4.3 is that the error MCHttpRepository>>#allFileNames creates when it cannot access the repos on Squeaksource stops the loading process. -- View this message in context: http://forum.world.st/now-that-squeaksource-is-back-tp4654045p4654207.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 6, 2012

Re: [Pharo-project] NativeBoost Dev

by Igor Stasenko

yeah.. it is really fuzzy thing: http://blog.xploiter.com/programming-related-content/cc-null-pointers/ On 6 November 2012 20:14, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 November 2012 20:02, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> Hi all, >> >> 2012/11/6 Igor Stasenko <siguctua(a)gmail.com> >>> >>> On 2 November 2012 06:05, Torsten Bergmann <astares(a)gmx.de> wrote: >>> > Hi Igor, >>> > >>> > in Win32 often one passes NULL as argument >>> > (for instance if a function has an argument "handle to a window", then >>> > a hWnd of NULL can be given). >>> > >>> > For instance when I have >>> > >>> > shellExecute: hwnd operation: lpOperation file: lpFile parameters: >>> > lpParameters directory: lpDirectory show: nShowCmd >>> > <primitive: #primitiveNativeCall module: >>> > #NativeBoostPlugin> >>> > >>> > ^ self nbCall: #( >>> > HINSTANCE ShellExecuteA( >>> > HWND hwnd, >>> > LPCTSTR lpOperation, >>> > LPCTSTR lpFile, >>> > LPCTSTR lpParameters, >>> > LPCTSTR lpDirectory, >>> > INT nShowCmd)) module: 'Shell32.dll' >>> > >>> >>> usually it controlled by options for code generator >>> like #optCoerceNilToNull >>> which will allow you to pass nil as valid argument. >>> >>> What is missing, is that in your case you passing an instance of >>> NBExternalObject, >>> and NBExternalObjectType converter does not honors that option. >>> This is easy to fix. I will add it as time allows me to do a pass on >>> NativeBoost. >>> >>> > >>> > The NBFFICallout class(NBNativeCodeGen >>> > class)>>handleFailureIn:nativeCode: >>> > tells me that "an instance of NBWin32Window" is expected. >>> > >>> right, so what you can do is to synthesize an instance of >>> NBWin32Window with handle value == 0. >>> This will effectively behave as if you passed null argument. Sure it >>> is not nearly elegant, so i mentioning it >>> just for protocol :) >>> >>> >>> > So currently I have to pass "NBWin32Window getFocus" as first >>> > argument. But often this is not necessary. >>> > >>> Another way of doing this is use convenience methods. Like with your >>> function, >>> you could have two methods for it, one which takes window argument, >>> and another which doesn't: >>> >>> >>> shellExecute: lpOperation file: lpFile parameters: lpParameters >>> directory: lpDirectory show: nShowCmd >>> >>> ^ self nbCall: #( >>> HINSTANCE ShellExecuteA( >>> 0, >>> LPCTSTR lpOperation, >>> LPCTSTR lpFile, >>> LPCTSTR lpParameters, >>> LPCTSTR lpDirectory, >>> INT nShowCmd)) module: 'Shell32.dll' >> >> >> yes I like this NB feature of directly put real values in external call >> definitions. >> But, having a NULL constant could also makes sense: >> >> ^ self nbCall: #( >> HINSTANCE ShellExecuteA( >> NULL, >> >> LPCTSTR lpOperation, >> LPCTSTR lpFile, >> LPCTSTR lpParameters, >> LPCTSTR lpDirectory, >> INT nShowCmd)) module: 'Shell32.dll' >> >> perhaps NULL is already there somewhere, I never look for it ;-) >> > > AFAIK, NULL pointer is not a standard part of ANSI C > the existance of > > #define NULL 0 > > in many implementations doesn't actually makes it "official" > > so, if you don't like putting 0 , you can always use class var with > value = 0 , and name it 'NULL' > 'NUL' or 'ZERO' or whatever you want :) > > >> Luc >> > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Nov. 6, 2012

Re: [Pharo-project] Pharo 2.0 and Metacello preview

by Igor Stasenko

and afaik, pharo vms coming with osprocess by default. so it is only about including osprocess to image. On 6 November 2012 16:24, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 6 November 2012 19:07, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 6 November 2012 16:00, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 6 November 2012 18:07, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> Basically, what is needed is: >>>> VMs with OSProcess installed by default >>>> Image(s) with OSProcess >>>> >>>> then Metacello Preview will be functional. >>>> >>>> The reason why , i personally want that, is >>>> to be able to use git for monticello. and be able to store C sources >>>> and smalltalk sources (VMMaker) in a single git repo. >>> >>> Igor, I assume then that neither Filetree nor Gitocello meet your >>> needs? (Both map Monticello repositories to git.) >>> >> Well, one of the reasons why i want a preview is to figure that out: >> does it fits or not, >> and what/how it can be used. > > Right, I've jumped the gun then. You want Metacello Preview precisely > so you can try out either/both/something else! > > frank > >>> frank >>> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Nov. 6, 2012

Re: [Pharo-project] NativeBoost Dev

by Igor Stasenko

On 6 November 2012 20:02, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi all, > > 2012/11/6 Igor Stasenko <siguctua(a)gmail.com> >> >> On 2 November 2012 06:05, Torsten Bergmann <astares(a)gmx.de> wrote: >> > Hi Igor, >> > >> > in Win32 often one passes NULL as argument >> > (for instance if a function has an argument "handle to a window", then >> > a hWnd of NULL can be given). >> > >> > For instance when I have >> > >> > shellExecute: hwnd operation: lpOperation file: lpFile parameters: >> > lpParameters directory: lpDirectory show: nShowCmd >> > <primitive: #primitiveNativeCall module: >> > #NativeBoostPlugin> >> > >> > ^ self nbCall: #( >> > HINSTANCE ShellExecuteA( >> > HWND hwnd, >> > LPCTSTR lpOperation, >> > LPCTSTR lpFile, >> > LPCTSTR lpParameters, >> > LPCTSTR lpDirectory, >> > INT nShowCmd)) module: 'Shell32.dll' >> > >> >> usually it controlled by options for code generator >> like #optCoerceNilToNull >> which will allow you to pass nil as valid argument. >> >> What is missing, is that in your case you passing an instance of >> NBExternalObject, >> and NBExternalObjectType converter does not honors that option. >> This is easy to fix. I will add it as time allows me to do a pass on >> NativeBoost. >> >> > >> > The NBFFICallout class(NBNativeCodeGen >> > class)>>handleFailureIn:nativeCode: >> > tells me that "an instance of NBWin32Window" is expected. >> > >> right, so what you can do is to synthesize an instance of >> NBWin32Window with handle value == 0. >> This will effectively behave as if you passed null argument. Sure it >> is not nearly elegant, so i mentioning it >> just for protocol :) >> >> >> > So currently I have to pass "NBWin32Window getFocus" as first >> > argument. But often this is not necessary. >> > >> Another way of doing this is use convenience methods. Like with your >> function, >> you could have two methods for it, one which takes window argument, >> and another which doesn't: >> >> >> shellExecute: lpOperation file: lpFile parameters: lpParameters >> directory: lpDirectory show: nShowCmd >> >> ^ self nbCall: #( >> HINSTANCE ShellExecuteA( >> 0, >> LPCTSTR lpOperation, >> LPCTSTR lpFile, >> LPCTSTR lpParameters, >> LPCTSTR lpDirectory, >> INT nShowCmd)) module: 'Shell32.dll' > > > yes I like this NB feature of directly put real values in external call > definitions. > But, having a NULL constant could also makes sense: > > ^ self nbCall: #( > HINSTANCE ShellExecuteA( > NULL, > > LPCTSTR lpOperation, > LPCTSTR lpFile, > LPCTSTR lpParameters, > LPCTSTR lpDirectory, > INT nShowCmd)) module: 'Shell32.dll' > > perhaps NULL is already there somewhere, I never look for it ;-) > AFAIK, NULL pointer is not a standard part of ANSI C the existance of #define NULL 0 in many implementations doesn't actually makes it "official" so, if you don't like putting 0 , you can always use class var with value = 0 , and name it 'NULL' 'NUL' or 'ZERO' or whatever you want :) > Luc > -- Best regards, Igor Stasenko.

Nov. 6, 2012