January 2013 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by StÃ©phane Ducasse

Thanks! On Jan 24, 2013, at 7:48 AM, Jan Vrany wrote: > Hi, > > we've made all SmallLint code in Smalltalk/X MIT-licensed. > Enjoy. > > Jan > > > On 22/01/13 23:59, StÃ©phane Ducasse wrote: >>> Well. I've written the tag support, so let's make it simple, MIT. >>> I may export a changeset with that code for you, if you like. >> >> Else I will just go over them and it will help me to understand. I think that this is not difficult. >> >>> For rules written by CG I'm not sure. You should check with him. >>> But I think it won't be a problem given that you preserve all >>> the signatures and #documentation and #version_XXX methods >>> (we use them to track changes in the source). >>> >>> However, what I planned (and run out of time :-) is to make >>> tag a first class object with name (symbol) description etc >>> and have class methods to create them. Then one may define and >>> describe meaning of the tag in an extension method. >>> Also, the selection/rejection logic could dispatch back on >>> the tag instance so you may then create fancy dynamic tags >>> (like #portability that automatically includes everything tagged >>> as #pharo #squeak #stx #va, for instance or whatever. >>> >>> I might hack it later this week, if you would include it into >>> your version (otherwise I've more important things to do :-) >> >> I imagine well. >> Let us keep it simple. Simple tags with a little class comments are good enough :) >> >>> >>> Cheers >>> >>> On 22/01/13 19:32, StÃ©phane Ducasse wrote: >>>> Jan >>>> what is the license of your tags and other code? >>>> >>>> Stef >>>> >>>> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: >>>> >>>>> On 22/01/13 18:22, StÃ©phane Ducasse wrote: >>>>>> Hi >>>>>> >>>>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that >>>>>> >>>>>> Checks that all subclassResponsibility methods are defined in all leaf classes. >>>>>> >>>>>> Now the results display the sender of ^ subclassResponsibility but I have to manually find the >>>>>> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. >>>>>> >>>>>> But this would be much better. Jan did you do that in your version? >>>>> >>>>> Good point. Yes, since now we do that :-) >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Stef >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > > <smalltalkx-lint.zip>

Jan. 24, 2013

Re: [Pharo-project] pharotaskforces broken on squeaksource

by StÃ©phane Ducasse

Ok I published a new version of the fix and let me know. Indeed removing the file physically would be good too. I do not have access to it. Stef > Indeed, I thought of that, too. But, the problem is that the web interface only shows one single package versions, probably because after the restart the index in the image was not updated. > > In any case, my original question was why do we have a ".mcz" file at all? But, I will look into the fix of Stef. And, tomorrow I will go to SCG and see if we can actually remove the offending file from the file system. > > Cheers, > Doru > > > On Jan 24, 2013, at 2:14 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Tudor Girba-2 wrote >>> Or how to fix this? >> >> The immediate problem can be fixed by deleting the version on sqs, no? >> Requires admin access i.e. StÃ©phane Ducasse, Alexandre Bergel, Marcus >> Denker, Alain Plantec >> >> >> >> -- >> View this message in context: http://forum.world.st/pharotaskforces-broken-on-squeaksource-tp4664764p4665… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >

Jan. 24, 2013

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

by StÃ©phane Ducasse

Jan. 24, 2013

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

by Sean P. DeNigris

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 ;) -- View this message in context: http://forum.world.st/Image-size-of-2-0-tp4665128p4665172.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 24, 2013

Re: [Pharo-project] destructive / regression tests

by Marcus Denker

On Jan 24, 2013, at 6:16 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 January 2013 18:12, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I've been thinking these days on how to implement regression tests. >> Obviously the core requirement is to launch a separate image and capture terminal output and/or result files. >> >> For now I will put them into a separate repository: >> >> http://smalltalkhub.com/#!/~Pharo/regression-testing >> >> Some question: >> - Is there a test ConfigurationOf* which can be used to try loading different versions / groups? >> - Is it ok to rely on OSProcess for now to run launch a separate new image? > > + 1 > we need such tests. > And actually it would be even useful to know which code crashing the > system , e.g. > we can even have a tests which succeed only if they crashing VM. Yes! We did a first (ad-hoc) regression tester for Opal: https://ci.inria.fr/rmod/job/OpalRegression/ We just have the tests in different packages and take care which to run when. The regression-test job runs first slow tests that can not do any harm (compiling all method, but not installing them), then as a second to run tests that recompile the whole image, this we save and then run all tests on that: ./vm.sh $JOB_NAME.image test --junit-xml-output "OpalCompiler-RegressionTests.*" ./vm.sh $JOB_NAME.image test --junit-xml-output "OpalCompiler-DestructiveRegressionTests.*" --save ./vm.sh $JOB_NAME.image test --junit-xml-output ".*" With that in place we can be quire sure that a change done on the compiler is not doing anything wrong. (and that speeds up development quite a lotâ¦) Marcus

Jan. 24, 2013

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

by Camillo Bruni

that's nice cause the whole information for Monticello and the ScriptLoader could be retrieved online on demand! On 2013-01-24, at 16:09, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > With Esteban we checked a bit image size. > > The download of 2.0 now has ca. 30MB, which is large. > > But: > > -> Delete Monticello history > -> Unload Scroptloader > -> do #cleanUpForRelease > > Result: 15.4MB, with all tests, NativeBoost, RB... > > This is not too bad! > > Marcus >

Jan. 24, 2013