- Pharo-dev - lists.pharo.org

Re: [Pharo-project] In-Image Fuel Documentation

by Sven Van Caekenberghe

On 24 Jan 2013, at 20:16, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > I eventually found this awesome website [1]. It would be great if there were > some basic examples in the image. I found the tests too well factored to be > used for this purpose. Even a HelpSystem entry simply pointing to [1] would > be really helpful for beginners like me ;) (although a full Help entry would > have the nice benefit of executable examples) > > Thanks, > Sean > > [1] > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8.1/Documentation This is very nice documentation ! Thanks for the pointer, and thanks Mariano for writing it - this is really great. Sven PS: IMHO the only thing we need is a way or a convention to document a Monticello package as a whole. That can then be the starting or entry point. Like README.md in github. This should then be in the code and browseable externally. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 24, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi: On 24 Jan 2013, at 20:29, Ciprian Teodorov wrote: > Hi Stefan, > > I've just tried libgit2 mapping generation on my machine, at it seems to work without any problems... (well besides the hack on the ChangesBrowser)... > Now the thing is that I have the latest packages of TalkFFI, and LibClang. So I recommend that you retry after updating the packages from the repository... Aaaah... Well, I update one of the things yesterday manually, and was not aware that there is a second repository. My TalkFFI packages were outdated. Well, and I needed to work the ordering issue, so I added CLForeignLibInterfaceGenerator>>#implement mappingModel model changes execute. Now the generation indeed succeeds :) However, trying to do something simple fails with a NBCog VM crash. I am not entirely sure whether I am doing it correct, and whether this is all GC save etc... So here we go with two examples: "try to get the repo head and its name" | repo repoPath cb branches headHandle | repo := NBExternalHandle new. repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. headHandle := NBExternalHandle new. LG2RepositoryH uniqueInstance repository_head: headHandle repo: repo. ^ LG2RefsH uniqueInstance reference_name: headHandle. The second one is a bit more complex, it has to use a callback: "try to read all the names of branches" | repo repoPath cb branches | LibGit2Map initialize. repo := NBExternalHandle new. repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. LG2RepositoryH uniqueInstance repository_open: repo path: repoPath. branches := OrderedCollection new. cb := LG2BranchHCb161 on: [:name :type :payload | branches add: name ]. LG2BranchH uniqueInstance branch_foreach: repo list_flags: 1 branch_cb: cb payload: NBExternalAddress null. ^ { repo. branches } So, now I am down to the question of how to use TalkFFI and NativeBoostFFI. Any idea what that could be? And how to diagnose these things? Thanks a lot Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 24, 2013

Re: [Pharo-project] In-Image Fuel Documentation

by Camillo Bruni

On 2013-01-24, at 21:03, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > On Thu, Jan 24, 2013 at 4:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> I eventually found this awesome website [1]. It would be great if there >> were >> some basic examples in the image. I found the tests too well factored to be >> used for this purpose. > > > what do you mean by this? > FLUserGuidesTest contains the examples used in the website (although there > may not be everything and still it could be outdated). > Maybe we can move this test into a Fuel-Examples package? > > >> Even a HelpSystem entry simply pointing to [1] would >> be really helpful for beginners like me ;) (although a full Help entry >> would >> have the nice benefit of executable examples) >> >> > Hi Sean. One problem I found is that then we have too many places with the > same doc. Hence, a simple update means changing a lot of places: > > - Doc in image > - Examples in image / tests > - Website > - Help system > - PBE chapter > > so...that does not scale. > > I don't know yet the best way to solve this. Markdown and then output all > the different pieces is not an option I think. > thoughts? For me the first place to put information is in the Image, hence I would only create a HelpDoc (using a common Markdown et. al scheme). The secondary thing is to output that to proper website to get a nice global index on google. This is specially useful if you do not have the code installed yet and you are looking for some piece of code doing a certain thing. Note that it happens way to often on this mailing list that people ask for something and reimplement it due to missing answers ;), google should answer you the right thing!

Jan. 24, 2013

Re: [Pharo-project] In-Image Fuel Documentation

by Sean P. DeNigris

Mariano Martinez Peck wrote > FLUserGuidesTest contains the examples used in the website Oops, didn't see that one! I went to the serialization tests and got lost. I guess what I'm suggesting is to have pointers to the prefered docs (in this case FLUserGuidesTest) where a user might look e.g. HelpSystem -- View this message in context: http://forum.world.st/In-Image-Fuel-Documentation-tp4665190p4665210.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 24, 2013

Re: [Pharo-project] In-Image Fuel Documentation

by Mariano Martinez Peck

On Thu, Jan 24, 2013 at 4:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I eventually found this awesome website [1]. It would be great if there > were > some basic examples in the image. I found the tests too well factored to be > used for this purpose. what do you mean by this? FLUserGuidesTest contains the examples used in the website (although there may not be everything and still it could be outdated). Maybe we can move this test into a Fuel-Examples package? > Even a HelpSystem entry simply pointing to [1] would > be really helpful for beginners like me ;) (although a full Help entry > would > have the nice benefit of executable examples) > > Hi Sean. One problem I found is that then we have too many places with the same doc. Hence, a simple update means changing a lot of places: - Doc in image - Examples in image / tests - Website - Help system - PBE chapter so...that does not scale. I don't know yet the best way to solve this. Markdown and then output all the different pieces is not an option I think. thoughts? > Thanks, > Sean > > [1] > > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8.1/Documentation > > > > -- > View this message in context: > http://forum.world.st/In-Image-Fuel-Documentation-tp4665190.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

Jan. 24, 2013

Re: [Pharo-project] Image size of 2.0...

by Sven Van Caekenberghe

On 24 Jan 2013, at 18:57, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> The download of 2.0 now has ca. 30MB, which is large. >> >> But... 15.4MB > > I am in awe that I can download the closest thing the world has ever come to > dynabook software in 20 seconds on my home internet. This is truly an > exciting time to be alive!! > > Cheers, > Sean > > p.s. 10 seconds for 15MB is even nicer... what will I do with the time ;) Fix Pharo bugs ? ;-) Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 24, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Ciprian Teodorov

Hi Stefan, I've just tried libgit2 mapping generation on my machine, at it seems to work without any problems... (well besides the hack on the ChangesBrowser)... Now the thing is that I have the latest packages of TalkFFI, and LibClang. So I recommend that you retry after updating the packages from the repository... However, I did not have time to compile the library and test if the bindings are usable. Let me know if you still have issues, maybe we could work them out ;) Ciprian Sidenote: LibGit2 project seems very interesting, it will be great if we manage to have a nice OO abstraction over it. On Thu, Jan 24, 2013 at 12:01 AM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi Ciprian: > > On 23 Jan 2013, at 22:06, Stefan Marr wrote: > > > Well, if I add all the headers manually to the generation, I run into > the trouble of the non-existing classes again. > > After working around the order issue, I am still running into more issues. > > Some of the classes for which methods are generated are completely missing > in the list of generated classes, and other changes in the list result in > colliding renames of callback classes. > > I will try to generate the bindings step by step, seeing what I actually > need. > > But if you would have a chance to look into these problems, that would be > great. > > Below I added the methods I used to generate the bindings. > > Thanks a lot > Stefan > > > !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr > 1/23/2013 22:04'! > libgit2Headers > ^ {'git2.h'. > 'git2/version.h'. > > 'git2/common.h'. > 'git2/threads.h'. > 'git2/errors.h'. > > 'git2/types.h'. > > 'git2/oid.h'. > 'git2/signature.h'. > 'git2/odb.h'. > > 'git2/repository.h'. > 'git2/revwalk.h'. > 'git2/merge.h'. > 'git2/graph.h'. > 'git2/refs.h'. > 'git2/reflog.h'. > 'git2/revparse.h'. > > 'git2/object.h'. > 'git2/blob.h'. > 'git2/commit.h'. > 'git2/tag.h'. > 'git2/tree.h'. > 'git2/diff.h'. > > 'git2/index.h'. > 'git2/config.h'. > 'git2/transport.h'. > 'git2/remote.h'. > 'git2/clone.h'. > 'git2/checkout.h'. > 'git2/push.h'. > > 'git2/attr.h'. > 'git2/ignore.h'. > 'git2/branch.h'. > 'git2/refspec.h'. > 'git2/net.h'. > 'git2/status.h'. > 'git2/indexer.h'. > 'git2/submodule.h'. > 'git2/notes.h'. > 'git2/reset.h'. > 'git2/message.h'. > 'git2/pack.h'. > 'git2/stash.h'.}! ! > > !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr > 1/3/2013 19:41'! > libgit2Mapping > | path includeDir options builder hFiles | > path := self libgit2Path. > includeDir := path / 'include'. > options := {('-I' , (path / 'include') fullName). > '-D__STDC_CONSTANT_MACROS'. > '-D__STDC_LIMIT_MACROS'}. > hFiles := self libgit2Headers. > builder := (CLForeign2NBGenerator for: #LibGit2) > platform: NativeBoostConstants mac32PlatformId libPath: > (path / 'build/libgit2.dylib') fullName; > compilationOptions: options; > includeDir: includeDir; > addHeaderFiles: hFiles; > classPrefix: 'LG2'; > ffiSelectorBlock: [ :selector | > (selector beginsWith: 'git_') > ifTrue: [ (selector > copyFrom: 4 to: selector size) withFirstCharacterDownshifted ] > ifFalse: [ selector > withFirstCharacterDownshifted ] ]; > ignoreUnsupported; > generate; > openChanges! ! > > !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr > 1/23/2013 15:06'! > libgit2Path > ^ FileReference / 'Users/smarr/tmp/libgit/libgit2'! ! > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 24, 2013

[Pharo-project] In-Image Fuel Documentation

by Sean P. DeNigris

I eventually found this awesome website [1]. It would be great if there were some basic examples in the image. I found the tests too well factored to be used for this purpose. Even a HelpSystem entry simply pointing to [1] would be really helpful for beginners like me ;) (although a full Help entry would have the nice benefit of executable examples) Thanks, Sean [1] http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8.1/Documentation -- View this message in context: http://forum.world.st/In-Image-Fuel-Documentation-tp4665190.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 24, 2013

Re: [Pharo-project] [squeak-dev] AndreasSystemProfiler Released MIT

by Eliot Miranda

On Wed, Jan 23, 2013 at 12:58 PM, Ron Teitelbaum <ron(a)usmedrec.com> wrote: > Hello All, > > In Memory of Andreas Raab > http://forum.world.st/In-Memory-of-Andreas-Raab-td4663424.html > > We have renamed and released the AndreasSystemProfiler. > Both AndreasSystemProfiler and MessageTally are periodic sampling profilers. The essential difference between AndreasSystemProfiler and MessageTally is in how the current method is sampled. MessageTally is driven from a high-priority process in a loop waiting on a delay. When the delay fires the lower-priority process being profiled is interrupted, its stack is walked to determine the methods along the call chain, and that data is recorded. But since the sampling occurs when the high-priority process preempts the lower-priority process, a sample is only taken at a preemption point. In particular, primitives are *not* profiled because they are not suspension points. A process can only be suspended on method activation (a non-primitive method activation, or primitive failure) or on backward branch. The cost of primitives is charged to a caller and is inferred by subtracting the cost of children of the caller from the caller itself (subtracting the number of samples in children of the caller form the number of samples in the caller itself). Another problem is that using the clock that underlies Delay, which is typically the clock used by processes being profiled, causes sampling errors due to the sampling and sampled processes cohering. Delays are limited in resolution (at best 1 millisecond) so if the profiled process waits on a delay it'll fire immediately after the profiling process (because the profiling process is at higher priority) and so the sampling process may only ever see the sampled process in a wait state. If MessageTally is used to profile multiple processes then a third problem is that if a primitive causes a process switch then its cost will end up being charged to the process switched-to, not switched from. This is again because sampling can only occur after a primitive has completed (successfully or not). AndreasSystemProfiler is driven from a high-priority process in a loop waiting on a Semaphore known to the VM. The profiling process uses a primitive to schedule a sample some number of ticks of the VM's high-performance clock in the future. When the time is reached the VM samples the current method and the current process, *before any process preemption takes place*, and independently of the standard clock, and signals the semaphore. The profiling process then collects the method,process pair via primitives. So AndreasSystemProfiler provides much more accurate results. That said there are still limitations with primitives and Cog. Currently Cog only samples "interpreter" primitives. Those primitives it implements in machine code (integer and float arithmetic, closure evaluation, at:, identityHash) are not sampled and won't show up; they will be charged to the calling method. This is fixable, since Cog actually compiles the sampling direct into interpreter primitive invocation when profiling is in effect and not at other times, but sampling could be a significant cost in these simple and performance-critical primitives. http://ss3.gemstone.com/ss/AndreasSystemProfiler.html > > Using the MIT License. > > Thank you Eliot for your help to get this ready. The profiler works with > Squeak 4.4. > > All the best, > > Ron Teitelbaum, Julie LeMoine and David Smith > > > -----Original Message----- > > From: squeak-dev-bounces(a)lists.squeakfoundation.org [mailto:squeak-dev- > > bounces(a)lists.squeakfoundation.org] On Behalf Of Andreas.Raab > > Sent: Friday, January 11, 2013 1:39 PM > > To: squeak-dev(a)lists.squeakfoundation.org > > Subject: [squeak-dev] Re: Profiling > > > > Levente Uzonyi-2 wrote > > > It uses some primitives which were added to the CogVM, so it requires > Cog. > > > We could reimplement it from scratch using the same primitives and get > > > a better profiler in the image. We can't include this due to the GPL > > > license. > > > > Or ask Ron if 3dicc (which bought all the rights to the Teleplace IP and > > Software) can re-release the code under a more permissable license. > > > > Cheers, > > - Andreas > > > > > > > > > > -- > > View this message in context: http://forum.world.st/Profiling- > > tp4662704p4662987.html > > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > > > > -- best, Eliot

Jan. 24, 2013

Re: [Pharo-project] looking for the description of the MC file package format convention

by StÃ©phane Ducasse

Jan. 24, 2013