- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Manifest class values - instance or class side

by Ben Coman

On Mon, May 18, 2015 at 10:02 AM, Sergio Fedi <sergio.fedi(a)gmail.com> wrote: > I want to add a test to ensure #packageManifest answers a Class. > > Since RPackage is in RPackageCore, but the #packageManifest method is in > Manifest-Core > I'm not sure whether: > > > 1. I have to make the test in RPackageTest but make the test method > from the Manifest-Core package > 2. I have to make the test in RPackageTest but make the test method > from the Manifest-Tests package > 3. Create a new class in Manifest-Tests to hold this new test (and > someupcoming tests as well) > > > > I'm not sure, but I am tending to towards... use of Manifest is an implementation detail. Its RPackage behaviour you are testing, so that is where the tests should

May 19, 2015

Re: [Pharo-dev] [Pharo-users] MongoTalk: new place on smalltalkhub

by Henrik Johansen

Hi! I made some (imho) improvements to the OID implementation, if someone with write access would find time to review/commit the attached package, I'd be grateful. The commit message: Make OID implementation more compatible with the description in http://docs.mongodb.org/manual/reference/object-id/. - Use the UNIX epoch instead of Smalltalk epoch for timestamp part, store BE so it's pseudo-sortable by time (also, you can use getTimestamp() in mongo shell and get a sensible value) - Use a per-session ID instead of localhost name for machine identification. localhost name is far from unique on some platforms (always 'localhost' on Macs), better with a unique ID per image session. - Counter initialized with a random value. As an added bonus, [OID new] bench should see a ~10% increase in performance. Cheers, Henry > On 08 Jul 2013, at 2:45 , FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: > > Hi, > > I've just created a new team for MongoTalk on SmalltalkHub: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam <http://www.smalltalkhub.com/#%21/%7EMongoTalkTeam> > > The old repo (http://www.smalltalkhub.com/#!/~francois/MongoTalk <http://www.smalltalkhub.com/#%21/%7Efrancois/MongoTalk>) will stay just in case some scripts rely on it but you should update to the new repo: > > http://www.smalltalkhub.com/#!/~MongoTalkTeam/mongotalk <http://www.smalltalkhub.com/#%21/%7EMongoTalkTeam/mongotalk> > > I've created a version 1.5.1 in the Metacello configuration to reflect the repo migration. > Shout at me if I missed something! > > Cheers, > Fa > > (Many thanks to Norbert for pushing the migration ;)

May 19, 2015

Re: [Pharo-dev] Manifest class values - instance or class side

by Sergio Fedi

Why scary? It seems that it was a part of the system not used. Maybe the scary part was to have something implemented that wasn't used?

May 19, 2015

[pharo-project/pharo-core]

by GitHub

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

May 19, 2015

[pharo-project/pharo-core] 019fca: 50050

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 019fca41ad12300d99e400a0be82a7cf18129606 https://github.com/pharo-project/pharo-core/commit/019fca41ad12300d99e400a0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-19 (Tue, 19 May 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50049.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50050.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50049.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50050.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/protocol/content.st A System-Support.package/ClassQueryTest.class/README.md A System-Support.package/ClassQueryTest.class/definition.st A System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st A System-Support.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st A System-Support.package/ClassQueryTest.class/instance/tests/testReferencedClasses.st A System-Support.package/MethodQueryTest.class/README.md A System-Support.package/MethodQueryTest.class/definition.st A System-Support.package/MethodQueryTest.class/instance/tests/testReferencedClasses.st A System-Support.package/extension/CompiledMethod/instance/referencedClasses.st M System-Support.package/extension/TBehavior/instance/referencedClasses.st R Tests.package/ClassQueryTest.class/README.md R Tests.package/ClassQueryTest.class/definition.st R Tests.package/ClassQueryTest.class/instance/dependencies/testReferencedClasses.st R Tests.package/ClassQueryTest.class/instance/tests/testAllCallsOn.st R Tests.package/ClassQueryTest.class/instance/tests/testAllCallsOnASymbol.st M Tool-Base.package/AbstractTool.class/instance/category/removeCategory_inClass_.st A Tool-Base.package/AbstractTool.class/instance/private/confirmAndRemoveCategory_inClass_.st Log Message: ----------- 50050 12358 Even if ---all--- can not be removed, all the methods can ... https://pharo.fogbugz.com/f/cases/12358 15550 TBehavior>>referencedClasses is wrong https://pharo.fogbugz.com/f/cases/15550 15500 SpecTreeNodeModel(Object)>>doesNotUnderstand: #content https://pharo.fogbugz.com/f/cases/15500 http://files.pharo.org/image/50/50050.zip

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 11:22 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 19 May 2015, at 10:32, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >>> >> And that view get the selection wrong ;) >> >> >> No, the ErrorNode has "all the rest" as it's extend for Shout so it can >> color the error just the same as people are used to. >> > > Ok. > > But I'd really like Shout not to color red the rest of the code when I > start to modify code half way through a method :) > > Is that inherent to the way ErrorNode instances are generated or is it > just done to maintain as it was? > > > I am not entirely sure... it sets the code of the ErrorNode to be just from > where we are to the end of the to be parsed text. > At that point it is hard to know the real extend of the error... needs to be > checked how to do it nicer. > In the example you give, the parser is able to trigger an error, go up the ast tree, and restart correct parsing further down the source code, no? Is that the way you are doing it? I'm interested in a general parsing theory for that kind of error detection / recovery. Thierry > > I think we should first get it in a state that we can replace the shout > parser (both for syntax highlight and code completion). > > Marcus >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Damien Pollet

On 18 May 2015 at 21:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > As for finding them: the nice property of syntax errors is that they are > trivial to detect staticallyâ¦ so e.g. we can add that people never can > commit code like that NOPE. The problem I had was that NBExternalStructure was changed from a variable bytes class to a normal one. So subclasses were committed without error but still couldn't be loaded with a more recent NB. Errors WILL happen, and fixing those is where plain text beats objectsâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> On 19 May 2015, at 10:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > >> >> And that view get the selection wrong ;) >> > > No, the ErrorNode has âall the restâ as itâs extend for Shout so it can color the error just the same as people are used to. > > Ok. > > But I'd really like Shout not to color red the rest of the code when I start to modify code half way through a method :) > > Is that inherent to the way ErrorNode instances are generated or is it just done to maintain as it was? > I am not entirely sureâ¦ it sets the code of the ErrorNode to be just from where we are to the end of the to be parsed text. At that point it is hard to know the real extend of the errorâ¦ needs to be checked how to do it nicer. I think we should first get it in a state that we can replace the shout parser (both for syntax highlight and code completion). Marcus

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Thierry Goubier

2015-05-19 10:27 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > >> > And that view get the selection wrong ;) > > > No, the ErrorNode has "all the rest" as it's extend for Shout so it can > color the error just the same as people are used to. > Ok. But I'd really like Shout not to color red the rest of the code when I start to modify code half way through a method :) Is that inherent to the way ErrorNode instances are generated or is it just done to maintain as it was? Thierry > > Marcus > >

May 19, 2015

Re: [Pharo-dev] Code generation for ASTs with syntax errors

by Marcus Denker

> > And that view get the selection wrong ;) > No, the ErrorNode has âall the restâ as itâs extend for Shout so it can color the error just the same as people are used to. Marcus

May 19, 2015