- Pharo-dev - lists.pharo.org

new configuration of XMLParser
by StÃ©phane Ducasse Nov. 24, 2013

Nov. 24, 2013

Hi guys I created a new configuration based on the work on monty for the XMLParser. Please test and let us know. In PharoExtras/XMLParser and available via the configurationBrowser. I merged its package and updated the configuration as well as added catalog meta data. Now it would be great if somebody would join maintaining this package. Thanks Monty Stef Name: ConfigurationOfXMLParser-StephaneDucasse.15 Author: StephaneDucasse Time: 24 November 2013, 6:44:05.130114 pm UUID: 4577e694-47fd-44b5-a301-78bf3a174987 Ancestors: ConfigurationOfXMLParser-DamienCassou.14 Enhancements made by Monty. These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: expiry := 1 year. (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') do: [:class | class selectors do: [:selector | | compiledMethod timeStamp | compiledMethod := class compiledMethodAt: selector. timeStamp := compiledMethod timeStamp copyAfter: Character space. (compiledMethod isDeprecated and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) ifTrue: [class removeSelector: selector]]].

1 0

Graphic System Arquitecture Question
by Ronie Salgado Nov. 24, 2013

Nov. 24, 2013

Hello, I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works. For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window. In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip. The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city. I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation. I believe that athens is a vector graphics API, which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done. Greetings, Ronie Salgado

3 3

Metacello Catalog job does not work anymore :(
by StÃ©phane Ducasse Nov. 24, 2013

Nov. 24, 2013

Hi guys https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/ is red and I did not change anything. Now when we copy artefact does it mean that they are copied or used by references? Then can we get the latest green job keeping its generation? Because now - no catalog - no idea why it breaks This is fun that everybody complains about description of packages and nobody cares except me to add meta data to the packages. well I have an idea but no idea how to fix it. Stef

1 0

Re: [Pharo-dev] Nautilus no longer guards against changed methods
by Stephan Eggermont Nov. 24, 2013

Nov. 24, 2013

Sean wrote: >Stephan Eggermont wrote >We need to revert to the modal behavior >In general in UIs, he best approach is to do what the user requests without hesitation, and make everything undoable. But obviously modal is better than losing changesâ¦ It is not that I donât find the old behavior annoying... A better solution than the modal one should - make it unattractive to have lots of open edits - make it easy to find all open edits - make it easy to compare open edits to the same method - make it impossible to lose edits accidentally and preferably - show which edits are compilable - show what is probably just a typo (some random character inserted somewhere in a method) Stephan

1 0

Slot class builder: Anonymous class modification
by Camille Teruel Nov. 24, 2013

Nov. 24, 2013

Hi everyone, With Esteban, we bumped into a problem with anonymous subclasses and the slot class builder. The problem is that once an anonymous class is created is not possible to modify it. Here is the problem: For creating an anonymous class with the new class builder API you do something like: myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder | classBuilder superclass: Object; name: #MyAnonymousClass; .... ] What happens is that the class builder asks the class installer if the class named #MyAnonymousClass exists or not to know if this a class to be created or to be modified. Here, the strategy of the anonymous class installer is to always answer no. So ok, now you have you're anonymous class. But what happens when you do something like: myAnonymousClass addInstVarNamed: #newIV Since the class has no clue of what class installer was used to create it, it instantiate a new one, and a PharoClassInstaller ! This new class installer then says to the class builder that there is no class named MyAnonymousClass so it creates it! And it install it in the system dictionary! And myAnonymousClass is not modified. So there is several problem here: - a class doesn't know which class installer was used to create it - even if the class would know that, the anonymous class installer would always say that it doesn't know it and a new class would be created So one possible solution for that is to have one class installer per environment (so add one iv in SystemDictionary right now), like that a class would know what class installer was used to create it. What would happen then is that you don't create anonymous classes anymore, that is to say a class not installed in any environment, but instead you create a class that exist in an environment separated from the system dictionary. What do you think?

9 16

[pharo-project/pharo-core] 956cac: 30592
by GitHub Nov. 24, 2013

Nov. 24, 2013

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 956cac73f7e635e47747477fb558fc537df07edb https://github.com/pharo-project/pharo-core/commit/956cac73f7e635e47747477f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-24 (Sun, 24 Nov 2013) Changed paths: A Deprecated30.package/extension/SmalltalkImage/instance/disableModuleLoading.st A Deprecated30.package/extension/SmalltalkImage/instance/forgetModule_.st A Deprecated30.package/extension/SmalltalkImage/instance/listBuiltinModule_.st A Deprecated30.package/extension/SmalltalkImage/instance/listBuiltinModules.st A Deprecated30.package/extension/SmalltalkImage/instance/listLoadedModule_.st A Deprecated30.package/extension/SmalltalkImage/instance/listLoadedModules.st A Deprecated30.package/extension/SmalltalkImage/instance/loadModule_.st A Deprecated30.package/extension/SmalltalkImage/instance/unloadModule_.st M Kernel.package/Exception.class/class/exceptionselector/%2C.st A Kernel.package/Exception.class/class/exceptionselector/-.st M Kernel.package/ExceptionSet.class/instance/exceptionselector/%2C.st A Kernel.package/ExceptionSet.class/instance/exceptionselector/-.st M Kernel.package/ExceptionSet.class/instance/exceptionselector/handles_.st M Kernel.package/ExceptionSet.class/instance/private/add_.st A Kernel.package/ExceptionSetWithExclusions.class/README.md A Kernel.package/ExceptionSetWithExclusions.class/definition.st A Kernel.package/ExceptionSetWithExclusions.class/instance/exceptionselector/-.st A Kernel.package/ExceptionSetWithExclusions.class/instance/exceptionselector/handles_.st A Kernel.package/ExceptionSetWithExclusions.class/instance/initialization/initialize.st A Kernel.package/ExceptionSetWithExclusions.class/instance/private/addExclusion_.st R Kernel.package/TimeStamp.class/class/instance creation/current.st A KernelTests.package/ExceptionTests.class/instance/testing-handling/testHandlingExceptionSetWithExclusion.st A KernelTests.package/ExceptionTests.class/instance/testing-handling/testHandlingWhenThereIsSomeExclusionButDontApplies.st A KernelTests.package/ExceptionTests.class/instance/testing-handling/testHandlingWithExclusion.st A KernelTests.package/ExceptionTests.class/instance/testing-handling/testHandlingWithSeveralExclusions.st A KernelTests.package/ExceptionTests.class/instance/testing-handling/testHandlingWithSeveralExclusionsAndExceptionSetsHandling.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script247.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30592.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Support.package/SmalltalkImage.class/instance/modules/disableModuleLoading.st R System-Support.package/SmalltalkImage.class/instance/modules/forgetModule_.st R System-Support.package/SmalltalkImage.class/instance/modules/listBuiltinModule_.st R System-Support.package/SmalltalkImage.class/instance/modules/listBuiltinModules.st R System-Support.package/SmalltalkImage.class/instance/modules/listLoadedModule_.st R System-Support.package/SmalltalkImage.class/instance/modules/listLoadedModules.st R System-Support.package/SmalltalkImage.class/instance/modules/loadModule_.st R System-Support.package/SmalltalkImage.class/instance/modules/unloadModule_.st Log Message: ----------- 30592 12227 Move System-Support deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/12227 12198 should remove TimeStamp Step2 https://pharo.fogbugz.com/f/cases/12198 12202 Exception Handling improvement to ignore some specific Exception https://pharo.fogbugz.com/f/cases/12202 http://files.pharo.org/image/30/30592.zip

1 0

[pharo-project/pharo-core]
by GitHub Nov. 24, 2013

Nov. 24, 2013

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

1 0

Nautilus no longer guards against changed methods
by Sven Van Caekenberghe Nov. 24, 2013

Nov. 24, 2013

I think this has been reported before, but in #30591 Nautilus no longer guards against changed methods. - Open Nautilus, select some method in some class - Change the methodâs source code, orange in top right corner - Click any other method, category, class or package - Pending change is lost This is pretty importart, I lost some changes already. Sven

2 2

Nov. 24, 2013

I will sycn the package and update the configuration. I added monty to the XMLReader and XMLWriter PharoExtras packages. Begin forwarded message: > From: "monty" <monty.os(a)engineer.com> > Subject: Re: Patches for Pharo packages you are maintaining > Date: November 24, 2013 3:17:01 AM GMT+01:00 > To: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > > I created a Smalltalkhub account and uploaded the latest versions of my packages there: http://smalltalkhub.com/#!/~monty/XMLPackages > > I was able to use the existing parsing infrastructure to build a tolerant HTML parser that produces a DOM tree. I am not sure if this should be standard or packaged separately. The relevant classes are in XML-Parser-HTML, if Damien (or whoever) wants to extract them. > > I also added support for standlone="yes" declarations and made the path resolution more robust. > > XMLParser now fully supports all the features of the XML 1.0 and namespaces 1.0 specs. This is a great news > >> ----- Original Message ----- >> From: StÃ©phane Ducasse >> Sent: 11/21/13 03:19 PM >> To: monty >> Subject: Re: Patches for Pharo packages you are maintaining >> >> > I don't have a Smalltalkhub account >> >> you should get one because it is cool and good. >> You should published there because when you publish the code it is explicit that this is under MIT. >> >> > and haven't signed any documents, but all my contributions have been derivative and should be automatically licensed under MIT (or whatever the original licenses of the packages are). >> >> MIT. >> It is important also for Pharo to have more contributors so if you can sign the license agreement I can like that archive it. :). >> >> Setf >> >> > >> > ----- Original Message ----- >> > From: StÃ©phane Ducasse >> > Sent: 11/21/13 06:17 AM >> > To: monty >> > Subject: Re: Patches for Pharo packages you are maintaining >> > ***excellent *** >> > >> > do you have an account on smalltalkhub so that I can give you access to it? >> > Did you sign the license agreement that you can find on the web? >> > >> > Stef >> > >> > >> > On Nov 21, 2013, at 3:14 AM, "monty" <monty.os(a)engineer.com> wrote: >> > >> >> Prof. Stef, I have produced updates to the XML-Parser, XML-Parser-Testing, and XML-Writer-Core packages you are maintaining. >> > >> > I'm not maintaining it, just making sure that we can load them. >> > >> >> These updates add validation against internal and external DTDs, proper replacement of general and parameter entites, customizable resolution of external parsed entities using Zinc and FileSystem, awareness of notations and unparsed entities, preservation of the internal DTD subset by the DOM parser (so printing a parsed doc with a DTD will produce approximately what was input), line numbers reporting in error messages, and better well-formed and validity constraints. >> >> >> >> I had to largely rewrite the tokenizer to make everything work, but I followed the spec closely, and it is about the same speed as long as there is no DTD to validate against. >> >> >> >> One problem is that while the tests I added and the existing tests all pass, for some reason helper messages in some test classes starting with "should" (in the style of should:raise:) are being interpreted as tests and run by TestRuner, even though they don't begin with "test" and take arguments! This is possibly a bug in TestRunner. >> > >> > Indeed this looks strange, >> > >> >> Another problem is that there are so many deprecated methods cluttering up classes, some of which have been deprecated for years! It is confusing and hard to see which methods to use just by browsing the protocols. I would really suggest using this code to get rid of the XML-Parser methods that have been deprecated for at least a year: >> > >> > Yes :) >> > >> > >> >> >> >> expiry := 1 year. >> >> (SystemNavigation default allClassesInPackageNamed: 'XML-Parser') >> >> do: [:class | >> >> class selectors do: [:selector | | compiledMethod timeStamp | >> >> compiledMethod := class compiledMethodAt: selector. >> >> timeStamp := compiledMethod timeStamp copyAfter: Character space. >> >> (compiledMethod isDeprecated >> >> and: [(DateAndTime now - (DateAndTime fromString: timeStamp)) > expiry]) >> >> ifTrue: [class removeSelector: selector]]]. >> >> >> >> I ran and checked it myself and it doesn't break anything. Running the above with XML-Writer-Core might not be a bad idea either. >> >> >> >> I also updated BitmapCharacterSet to use less memory. >> > >> > excellent >> > With metacello we will just create a new version/baseline and people relying on XML can choose when they want to migrate. >> > >> >> <XML-Writer-Core-monty.5.mcz><XML-Tests-Parser-monty.27.mcz><XML-Parser-monty.173.mcz><Collections-BitmapCharacterSet-Anonymous.6.mcz><Collections-BitmapCharacterSet-Anonymous.6.mcz> >

1 0

[pharo-project/pharo-core]
by GitHub Nov. 23, 2013

Nov. 23, 2013

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

1 0