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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30715 Home: https://github.com/pharo-project/pharo-core

Jan. 24, 2014

About doing things late (1 month before release)

by Marcus Denker

Hi, We *really* need to take care. >From what I see, people under-estimate just how much everything has consequencesâ¦ *every*thing that we do will need multiple iterations. Please make sure to take that into account when pushing for something to be added to Pharo3 instead of waiting for Pharo4. Marcus

Jan. 24, 2014

[update 3.0] #30719

by Marcus Denker

30719 ----- 12703 revert DockingBarMorph>>updatePosition https://pharo.fogbugz.com/f/cases/12703 12704 clean FontMorphChooser https://pharo.fogbugz.com/f/cases/12704 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.253… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FreeType-MarcusDenker.653.diff

Jan. 24, 2014

[update 3.0] #30718

by Marcus Denker

30718 ----- 12519 Codepanel in ByteCode view should be read only https://pharo.fogbugz.com/f/cases/12519 12693 TasklistMorph Navigation Cleanup https://pharo.fogbugz.com/f/cases/12693 12705 Better implementation of a method from case 12163 https://pharo.fogbugz.com/f/cases/12705 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.620.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Polymorph-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-Widgets-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Nautilus-MarcusDenker.668.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Keymapping-Core-MarcusDenker.…

Jan. 24, 2014

Re: [Pharo-dev] [Pharo-users] ConfigurationOfNacl

by Esteban Lorenzano

btwâ¦ you can add a job in pharo-contribution (public and free :P ), https://ci.inria.fr/pharo-contribution that will run all the tests (in all platforms, if needed), so you can be sure tests pass :) Esteban On 24 Jan 2014, at 09:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hernan, > > thanks for you contribution. But it does not works in mac :( > > 1) Smalltalk os isMac does not exists, now is Smalltalk os isMacOSX > 2) after fixing that, tests does not run either :( > > Esteban > > On 24 Jan 2014, at 07:25, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > >> I have added ConfigurationOfNacl to Pharo 3 repository. You can load it using the Configuration Browser. >> >> Nacl is a cryptolibrary based in libsodium. The binding for Pharo/Squeak (http://www.eighty-twenty.org/index.cgi/tech/smalltalk/nacl-for-squeak-and-p…) was written by Tony-Garnock Jones. >> >> The Configuration automatically download and uncompress the compiled library file. I have tested under Windows and Linux, all tests passes. But I do not own a Mac (I'm really open to donations :) so if anyone may test the configuration under Mac it would be nice. >> >> Cheers, >> >> HernÃ¡n >> >

Jan. 24, 2014

Re: [Pharo-dev] [Pharo-users] ConfigurationOfNacl

by Esteban Lorenzano

Hernan, thanks for you contribution. But it does not works in mac :( 1) Smalltalk os isMac does not exists, now is Smalltalk os isMacOSX 2) after fixing that, tests does not run either :( Esteban On 24 Jan 2014, at 07:25, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > I have added ConfigurationOfNacl to Pharo 3 repository. You can load it using the Configuration Browser. > > Nacl is a cryptolibrary based in libsodium. The binding for Pharo/Squeak (http://www.eighty-twenty.org/index.cgi/tech/smalltalk/nacl-for-squeak-and-p…) was written by Tony-Garnock Jones. > > The Configuration automatically download and uncompress the compiled library file. I have tested under Windows and Linux, all tests passes. But I do not own a Mac (I'm really open to donations :) so if anyone may test the configuration under Mac it would be nice. > > Cheers, > > HernÃ¡n >

Jan. 24, 2014

Re: [Pharo-dev] <quote author="Sean P. DeNigris"> I think the tree nodes should be based on name-matching and not only per-package. For example: </quote> In 4.0, let's query the Metacello configurations to find out exactly what packages belong to which project and categorize from there, but until then, I think this is already an improvement:

by Goubier Thierry

Sean, I find this very interesting. Le 24/01/2014 03:11, Sean DeNigris a Ã©crit : > > I think the tree nodes should be based on name-matching and not only > per-package > I should've appended: "as a compromise for the time being"... > > In 4.0, imagine this killer combination: > - Declare high-level logical categories a la AltBrowser (e.g. UI). This > really nails the 7+/-2 sweet spot > - For external projects, query the Metacello configurations to find out > exactly what packages belong to which project and group accordingly; > they could also declare AltBrowser categories Querying the metacello configuration is a great idea... Then, when loading a package, I could refer to a configuration and a group as a way to classify them? AltBrowser is currently not very good at loading a large set of packages (for example, seaside) and recreate higher-level categories on the fly. The code to move from: | - Platform-Core to : | - Platform | + Core + Tests (i.e. creation of a higher level Platform category node) upon loading or creation of Platform-Tests can be a bit tricky, especially when computing the level of tree refreshing needed. You gave me another idea: in AltBrowser, there is an API for filtering the tree contents based on the environment (i.e. scoped browsing, if a tree node model is not in the environment, it isn't displayed in the tree). Now I could add more categories (based on the configurations loaded, for example), and, if empty, they would not appear in the tree. However, adding packages would put them in the right place. Cool. Lots of things to try :) Thanks, Thierry > But until then, I think this is already an improvement: > The screenshot is of two overlapping Nautilus browsers. The one on the > left is the current implementation. The one on the right adds top-level > categories. The key thing to notice is the scroll bar: > almost 10 pages to deal with currently vs. 3-4 with top level categories. > Notice also that the icons make it clear what is an actual package. > > The other important thing to remember is that power users are most > likely going to use Spotlight or the filter bar. This is really more for > exploration and education. > > Cheers, > Sean -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Jan. 24, 2014

Re: [Pharo-dev] some hand holding with git and the pharovm tree please...

by Max Leske

git fetch *does* fetch everything from remote but does *not* merge new objects into the working tree. For that you need to do `git pull` (make sure that your working tree is clean by either committing first or stashing your changes with `git stash`). After pulling, run `git log` to see the commits. On 24.01.2014, at 00:20, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > in trying to help ClÃ©ment with his Sista work on Cog I'm trying to look at the latest version of pharovm. I've been using git://gitorious.org/cogvm/blessed. > > > I cloned it on December 2nd, and just did a git fetch, but I see no changes to any files other than .git/FETCH_HEAD and .git/ORIG_HEAD. How do I update the files to their current state (I use svn & mercurial, have used sccs, rcs & sccs, and it's such a pain having to learn yet another f***ing sccs)? > > Further, I see no generated files such as gcc3x-cointerp.c or cogit.c. Why not? Do you always fire up an image and freshly generate the C source?? If not, where do I find it? > > All this is to answer the simple question of whether the blessed pharo vm contains primitiveInterpreterSourceVersion. How would you answer that question without running the VM? > > e.g. in the Cog svn repository you'd do > grep primitiveInterpreterSourceVersion src/vm/*.c src/plugins/*/*.c > and you'd have an answer. > > I tried > cd mc/VMMaker-oscog.package/instance > grep primitiveInterpreterSourceVersion *.st > and the lack of reply makes me think it doesn't exist. Hence from > > !VirtualMachine methodsFor: 'accessing' stamp: 'MarcusDenker 5/8/2013 11:51'! > interpreterSourceVersion > "The use of this primitive not recommended. Not all VMs providing that" > > "Answer a string corresponding to the version of the interpreter source. > This represents the version level of the Smalltalk source code (interpreter > and various plugins) that is translated to C by a CCodeGenerator, as distinct > from the external platform source code, typically written in C and managed > separately for each platform. An optional primitive is invoked that may not > be available on all virtual machines." > > "Smalltalk vm interpreterSourceVersion" > > <primitive: 'primitiveInterpreterSourceVersion'> > ^ self getSystemAttribute: 1009! ! > > I can tell I need to look at the implementation of sourceVersionString in platforms/Cross/vm/sqSCCSVersion.h, which, despite all my best efforts, has diverged completely (and IMO unnecessarily) from http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/sqSCCSVe…, (which was written to be extended to satisfy us all). It reads > > /* > * A set of definitions for C source code control systems, to provide accurate > * and definitive version information to the VM. > * > * Currently instantiated only for Subversion. Please add definitions for > * other repositories as appropriate. > * > * I guess a good way to manage this is to edit the below define list to select > * appropriate the repository type, and then that's the extent of the fork. > * > * Eliot Miranda > * eliot.miranda(a)gmail.com > * 15 July 2011 > */ > > > #include "vmVersionInfo.h" // defines REVISION_STRING > > #ifndef REVISION_STRING > # error "Revision information not specified" > #endif > > static char *sourceVersionString() > { > return REVISION_STRING; > } > > which is wrong. I *didn't* write this. I wrote something quite different and you should have edited it to reflect that. > > But alas, when I try > find . -iname vmVersionInfo.h > I find...nothing. > > hmph. stymied. frustrated. confused. hence this missive. > > P.S> What I'm really trying to do is get my VM simulator to say it's a Pharo VM, so I can simulate ClÃ©ment's Sista image and fix the infrastructure he's trying to use for speculative inlining/adaptive optimization. So this is in aid of a (much) faster Pharo VM. Hence helpful answers only please. > -- > best, > Eliot

Jan. 24, 2014

Re: [Pharo-dev] [update 3.0] #30717

by Marcus Denker

On 24 Jan 2014, at 08:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > (other mail as the diff sender job is brokenâ¦ diffs fro 30715 an 716 are coming as soon as that is > fixed). > > 30717 > ----- > > 12684 NewValueHolder Enhancements > https://pharo.fogbugz.com/f/cases/12684 Hmmmâ¦ 1) now we have test failing: ReleaseTest testObsoleteClasses Obsolete classes remaining: an Array(AnObsoleteNewValueHolder AnObsoleteCollectionValueHolder) 2) Does it have compatibility implications? Renaming classes one month before a release without keeping the older name? Maybe itâs just internal? 3) That definitely should be a Slot! :-) Marcus

Jan. 24, 2014

[update 3.0] #30717

by Marcus Denker

Jan. 24, 2014