Re: [Pharo-dev] Pratt Parsers for PetitParser
On 11 Jun 2015, at 09:30, Jan Kurš k...@iam.unibe.ch wrote: That sounds really cool and useful extension. Thank you Jan! Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? Yes, with furthest failure I get errors from tokenization instead of my errors. For exemple with the calculator grammar I gave in my first mail when I parse ‘1+’ the furthestFailure is ‘$- expected at 2’ whereas I return ‘expression expected at 2’ because there's a whole expression missing. Same thing with ‘(1+2’ that returns ‘digit expected at 4’ instead of ‘$) expected at 4’. But furthest failure gives wrong messages in other cases to. Consider this sequence parser: keyword := #letter asParser plus , $: asParser. keyword parse: ‘foo' This returns 'letter expected at 3’, but no matter how many letters I add to the end I’ll still get ‘letter expected’. I want to get what is really missing: '$: expected at 3’. Maybe returning the “latest furthest failure” instead of the “first furthest failure” could solves the problem here (i.e. replacing with = in PPContext#noteFailure:)? One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ Indeed, my hack (redefining #parseWithContext:) works only when the Pratt parser is the top parser, but a soon as I compose it I’m screwed because only parseOn: is sent to the Pratt parser. That’s why I wonder if letting the parser decide what to return wouldn’t solve the problem: by default the furthest failure but special parsers can still decide. Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? The Pratt tokens are special: a token points back to the parser that generated it (its “kind”). PPTokenKind subclasses PPFlatteningParser and generates instances of PPPrattToken. A PPTokenKind stores the precedence, the action to be executed when a token of this kind is met at the start of an expression (for terminals and prefixes) and the action to be executed when a token is met in the middle of an expression (for postfixes and infixes). Cheers, Camille Cheers Jan On Wed, Jun 10, 2015, 20:52 Richard Sargent richard.sarg...@gemtalksystems.com mailto:richard.sarg...@gemtalksystems.com wrote: camille teruel wrote On 10 Jun 2015, at 19:11, Chris Cunningham lt; cunningham.cb@ gt; wrote: Inteteresting On Wed, Jun 10, 2015 at 9:36 AM, Camille lt; camille.teruel@ lt;mailto: camille.teruel@ gt; wrote: Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. snip @PP Devs: I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). But I guess it was introduced because it gives good results in other cases. So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? The intent behind the furthestFailure is that it give the failure that gets the furthest into the source stream. It is most useful when there are embedded choice operators in the parser - the original/pre furthest behaviour would return the last failure, which depending on the incoming stream and the order of the choice options could be significantly not useful. I ran into this when working with the sql parser, which started off with the outer choice of (by memory): ^ selectStatement / insertStatement / updateStatement / deleteStatement If I was trying to part a select statement that had an error at the very end of the statement, the parser would return an error talking about how the incoming stream failed in deleteStatement. Not useful. I would be saddened if this further failure was not available. Yes in that case returning the furthest failure gives better results. However, this don’t give meaningful messages in all cases. For exemple with the calculator I gave in my previous message, if I parse ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns ‘$- expected at 2'. I’m not proposing to remove this feature but to let parsers decide to use it or not. Something like
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
Esteban wrote: If you want to contribute just tell Esteban so he can add you to the project. well no… I just made it public access, so anyone can commit changes there… :) (And I will move it to PharoExtras team soon, that’s the correct place once integrated in image… but well… time is tyrant :P) I moved it to PharoExtras, MCZs are copied and config adopted (with a new version 0.5): http://smalltalkhub.com/#!/~PharoExtras/CatalogBrowser/ This is tracked for integration in: https://pharo.fogbugz.com/f/cases/15744/CatalogBrowser-moved-to-PharoExtras BTW: IMHO we can close https://pharo.fogbugz.com/f/cases/15703/ Thanks T.
[Pharo-dev] [pharo-project/pharo-core] eadef9: 50105
Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: eadef90589fff2e2b12c6773b0a0acc98cf97b08 https://github.com/pharo-project/pharo-core/commit/eadef90589fff2e2b12c6773b0a0acc98cf97b08 Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-06-11 (Thu, 11 Jun 2015) Changed paths: M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/README.md A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline05_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/baselines/baseline06_.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/development_.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version05_.st M NautilusRefactoring.package/ChangesBrowser.class/definition.st A NautilusRefactoring.package/ChangesBrowser.class/instance/accessing/changes_.st A NautilusRefactoring.package/ChangesBrowser.class/instance/accessing/pickedChanges.st R NautilusRefactoring.package/ChangesBrowser.class/instance/api/buildDiffFor_.st R NautilusRefactoring.package/ChangesBrowser.class/instance/api/change_.st A NautilusRefactoring.package/ChangesBrowser.class/instance/private/buildDiffFor_.st R NautilusRefactoring.package/ChangesBrowser.class/instance/private/changes_.st R NautilusRefactoring.package/ChangesBrowser.class/instance/private/pickedChanges.st M NautilusRefactoring.package/ChangesBrowser.class/instance/private/updateChanges.st R RPackage-Core.package/RPackage.class/instance/accessing/removeDefinedMethod_forClass_.st R RPackage-Core.package/RPackage.class/instance/system compatibility/includesMethodReference_.st A RPackage-Core.package/RPackageOrganizer.class/class/class initialization/registerInterestToSystemAnnouncement.st A RPackage-Core.package/RPackageOrganizer.class/class/class initialization/unregisterInterestToSystemAnnouncement.st A RPackage-Core.package/RPackageOrganizer.class/class/private/methodAdded_.st A RPackage-Core.package/RPackageOrganizer.class/class/quieries/isPackageDefinedForClass_.st R RPackage-Core.package/RPackageSet.class/instance/system compatibility/includesMethodReference_.st A RPackage-Core.package/extension/MCPackage/instance/correspondingRPackage.st A RPackage-Core.package/extension/MCPackageManager/class/unregisterForNotifications.st A RPackage-Core.package/extension/String/instance/asPackage.st A RPackage-Core.package/extension/String/instance/asPackageIfAbsent_.st R RPackage-SystemIntegration.package/ClassRepackaged.class/README.md R RPackage-SystemIntegration.package/ClassRepackaged.class/class/instance creation/classRepackaged_oldPackage_newPackage_.st R RPackage-SystemIntegration.package/ClassRepackaged.class/definition.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/classRepackaged.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/classRepackaged_.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/newPackage.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/newPackage_.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/oldPackage.st R RPackage-SystemIntegration.package/ClassRepackaged.class/instance/accessing/oldPackage_.st R RPackage-SystemIntegration.package/MethodRepackaged.class/README.md R RPackage-SystemIntegration.package/MethodRepackaged.class/class/instance creation/methodRepackaged_oldPackage_newPackage_.st R RPackage-SystemIntegration.package/MethodRepackaged.class/definition.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/methodRepackaged.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/methodRepackaged_.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/newPackage.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/newPackage_.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/oldPackage.st R RPackage-SystemIntegration.package/MethodRepackaged.class/instance/accessing/oldPackage_.st R RPackage-SystemIntegration.package/PackageChecker.class/README.md R RPackage-SystemIntegration.package/PackageChecker.class/definition.st R RPackage-SystemIntegration.package/PackageChecker.class/instance/check/check.st R RPackage-SystemIntegration.package/extension/MCPackage/instance/correspondingRPackage.st R RPackage-SystemIntegration.package/extension/MCPackageManager/class/unregisterForNotifications.st R
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50105 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
Hi, On 11 Jun 2015, at 08:55, Torsten Bergmann asta...@gmx.de wrote: Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. this is the most important, so people can actually know what a project is about :) but of course, that depends on you providing information in catalog methods! The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. What to do next: - give feedback - we should update all our configs with catalog descriptions please, this is vital to have a good entry point to your projects. - it would be nice if the spotter integration would include also a preview of the project description +1 - ... If you want to contribute just tell Esteban so he can add you to the project. well no… I just made it public access, so anyone can commit changes there… :) (And I will move it to PharoExtras team soon, that’s the correct place once integrated in image… but well… time is tyrant :P) Esteban ps: Thanks Torsten to look at it! Thanks Esteban Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964.html [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/jsoncatalogBrowser.png
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann asta...@gmx.de wrote: Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Just had a quick try. Its nice to get descriptions, like for TaskIT. However I think there should be a confirmation dialog before actually loading a Configuration, which is a potentially destructive/undoable action. Its too easy that habits pressing enter for other functions assert themselves and load a configuration accidentally. Perhaps an alternative is to open a window with more information from the other fields of the catalog that has a button to load the Configuration. Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. I don't think its a total replacement for the Configuration Browser. The new function suits the case of searching for a configuration you already know about, bu tmany times I like catalog browsers when I'm not searching for something. That is, when I don't know what is there and I'm *browsing*. Indeed, if you are searching for a particular configuration then you probably already know what it is and the additional info is then not needed. cheers -ben What to do next: - give feedback - we should update all our configs with catalog descriptions - it would be nice if the spotter integration would include also a preview of the project description - ... If you want to contribute just tell Esteban so he can add you to the project. Thanks Esteban Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964.html [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/json
Re: [Pharo-dev] Probably Metacello sucks…
On 11/06/15 07:52, Yuriy Tymchuk wrote: Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? What I've done is get all latest versions out of smalltalkhub and collect the signatures that are used. That can provide upper and lower limits of possible versions. Stephan
Re: [Pharo-dev] Pharo 4, format on accept/display
The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. It formats code on accept and/or display using the RBConfigurableFormatter. Marcus Denker-4 wrote On 11 Jun 2015, at 08:16, Peter Uhnák lt; i.uhnak@ gt; wrote: If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. Yes, but we do make exceptions… e.g. I added format on display and accept to Pharo3 after the release, because it is indeed a nice thing to have. So in that sense not having it in Pharo4 is kind of a bug. The version we get in Pharo5 will come with a new pretty printer, we will not back port that, so doing a “minimally intrusive” version for Pharo4 makes sense. Marcus -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Detecting the context/producer of code change announcements
On Thu, Jun 11, 2015 at 2:29 AM, Max Leske maxle...@gmail.com wrote: On 10 Jun 2015, at 17:13, Martin Dias tinchod...@gmail.com wrote: Hi everybody, I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance. My point is that there are operations like MC version load, change set file in, RB refactoring execution, or class copy that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a high-level operation, or if it was manually performed by the user in the Nautilus browser. I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover lost changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some high-level operations, but Epicea would need support from Pharo for a nice implementation. Brainstorming on implementations. I think announcements are a good mechanism to implement this feature. A simple approach is to provide begin and end announcements (e.g. MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like: MCVersionLoader load ... SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: ...). [ ... produce code changes ... ] ensure: [ SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd versionName: ...) ]. which may be re-written with a convenience method as: ... SystemAnnouncer uniqueInstance announceBefore: (MCVersionLoadBegin versionName: ...) announceAfter: (MCVersionLoadEnd versionName: ...) do: [ ... produce code changes ... ] but, going one step further, we could reify the concept of announcement begin and end like: ... announcement := (MCVersionLoad versionName: ...). SystemAnnouncer uniqueInstance announceBefore: (AnnouncementBegin of: announcement) announceAfter: (AnnouncementEnd of: announcement) do: [ ... produce code changes ... ] which could be re-written as: ... SystemAnnouncer uniqueInstance announceBeforeAndAfter: (MCVersionLoad versionName: ...) do: [ ... produce code changes ... ] I think any approach can work, but I'd love to have some feedback. I like the idea. What I’m afraid of is however, that the dependency between begin and end announcements is implicit in your examples. The only things that tell you that they belong together are the convenience implementation on SystemAnnouncer and the naming. I’m not familiar enough with announcements to post example code. The other thing would maybe be to force subscribers to subscribe to both announcements (again, not sure how). My point is, I want to look at one of the announcements and see that I have to work with a set of announcements. Ben’s idea of hierarchichal announcements sounds pretty interesting. Maybe this is too restricting but how about saying: there exists a dependency between two announcements A and B such that whenever A is being announced, B has to have been announced before (I’ll leave the implementation to others :p). The other thing would be to clean up the announcer situation… Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if you’re interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer. Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children. cheers -ben I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max Kind regards, Martín
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50106 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] Pharo 4, format on accept/display
Thanks, I will have a look. On 11 Jun 2015, at 16:39, Paul DeBruicker pdebr...@gmail.com wrote: The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. It formats code on accept and/or display using the RBConfigurableFormatter. Marcus Denker-4 wrote On 11 Jun 2015, at 08:16, Peter Uhnák lt; i.uhnak@ gt; wrote: If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. Yes, but we do make exceptions… e.g. I added format on display and accept to Pharo3 after the release, because it is indeed a nice thing to have. So in that sense not having it in Pharo4 is kind of a bug. The version we get in Pharo5 will come with a new pretty printer, we will not back port that, so doing a “minimally intrusive” version for Pharo4 makes sense. Marcus -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
On Thu, Jun 11, 2015 at 11:11 PM, Esteban Lorenzano esteba...@gmail.com wrote: On 11 Jun 2015, at 16:42, Ben Coman b...@openinworld.com wrote: On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann asta...@gmx.de wrote: Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Just had a quick try. Its nice to get descriptions, like for TaskIT. However I think there should be a confirmation dialog before actually loading a Configuration, which is a potentially destructive/undoable action. Its too easy that habits pressing enter for other functions assert themselves and load a configuration accidentally. Perhaps an alternative is to open a window with more information from the other fields of the catalog that has a button to load the Configuration. Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. I don't think its a total replacement for the Configuration Browser. The new function suits the case of searching for a configuration you already know about, bu tmany times I like catalog browsers when I'm not searching for something. That is, when I don't know what is there and I'm *browsing*. Indeed, if you are searching for a particular configuration then you probably already know what it is and the additional info is then not needed. But is a superset. We do not want to keep two tools with same functionality (we already did this a lot in the past, but we are like alcoholics in recovery now… :P) Esteban ps: when you already know what you want, most probably you just load through a command line (or a script)… at least that’s what I do :) I worked out that typing #cat gave me what I wanted. However when I down-arrow from GraphViz, it cycles back to the top to A4BP. I can't believe there are no configurations after GraphViz :) cheers -ben
[Pharo-dev] [pharo-project/pharo-core] cdf159: 50106
Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: cdf1593f415e3d68410dc04b992fb195615bceeb https://github.com/pharo-project/pharo-core/commit/cdf1593f415e3d68410dc04b992fb195615bceeb Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-06-11 (Thu, 11 Jun 2015) Changed paths: M ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/accessing/defaultRepositoryUrl.st M Reflectivity.package/HookGenerator.class/instance/result/preamble.st R Reflectivity.package/RFArg1ReificationNode.class/README.md R Reflectivity.package/RFArg1ReificationNode.class/definition.st R Reflectivity.package/RFArg1ReificationNode.class/instance/visiting/acceptVisitor_.st A Reflectivity.package/RFArgumentsReification.class/instance/generate/genForRBMessageNode.st R Reflectivity.package/RFArgumentsReification.class/instance/generate/genForRBProgramNode.st A Reflectivity.package/RFArgumentsReification.class/instance/generate/preamble_.st A Reflectivity.package/RFEReceiverReification.class/instance/generate/genForRBMessageNode.st A Reflectivity.package/RFEReceiverReification.class/instance/generate/preamble_.st R Reflectivity.package/RFNewValueReification.class/instance/generate/preamble.st A Reflectivity.package/RFNewValueReification.class/instance/generate/preamble_.st A Reflectivity.package/RFReceiverReificationNode.class/README.md A Reflectivity.package/RFReceiverReificationNode.class/definition.st A Reflectivity.package/RFReceiverReificationNode.class/instance/accessing/numargs.st A Reflectivity.package/RFReceiverReificationNode.class/instance/accessing/numargs_.st A Reflectivity.package/RFReceiverReificationNode.class/instance/visiting/acceptVisitor_.st R Reflectivity.package/RFReification.class/instance/as yet unclassified/genForRBTemporaryNode.st A Reflectivity.package/RFReification.class/instance/generate/genForRBTemporaryNode.st R Reflectivity.package/RFReification.class/instance/generate/preamble.st A Reflectivity.package/RFReification.class/instance/generate/preamble_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/declareVariableNode_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitArgumentsReificationNode_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitReceiverReificationNode_.st A Reflectivity.package/extension/CompiledMethod/instance/blockNodes.st A Reflectivity.package/extension/CompiledMethod/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/CompiledMethod/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/CompiledMethod/instance/sendNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableReadNodes.st A Reflectivity.package/extension/CompiledMethod/instance/variableWriteNodes.st A Reflectivity.package/extension/OCASTTranslator/instance/visitArgumentsReificationNode_.st A Reflectivity.package/extension/OCASTTranslator/instance/visitReceiverReificationNode_.st A Reflectivity.package/extension/RBMethodNode/instance/assignmenNodes.st A Reflectivity.package/extension/RBMethodNode/instance/blockNodes.st A Reflectivity.package/extension/RBMethodNode/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/RBMethodNode/instance/sendNodes.st A Reflectivity.package/extension/RBMethodNode/instance/tempVariableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableReadNodes.st A Reflectivity.package/extension/RBMethodNode/instance/variableWriteNodes.st A Reflectivity.package/extension/RBVariableNode/instance/isDefinition.st A Reflectivity.package/extension/TClassDescription/instance/blockNodes.st A Reflectivity.package/extension/TClassDescription/instance/instanceVariableReadNodes.st A Reflectivity.package/extension/TClassDescription/instance/instanceVariableWriteNodes.st A Reflectivity.package/extension/TClassDescription/instance/sendNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableReadNodes.st A Reflectivity.package/extension/TClassDescription/instance/variableWriteNodes.st A Reflectivity.package/extension/TClassDescription/instance/variables.st A Reflectivity.package/extension/TRBProgramNodeVisitor/instance/visitArgumentsReificationNode_.st A Reflectivity.package/extension/TRBProgramNodeVisitor/instance/visitReceiverReificationNode_.st R
Re: [Pharo-dev] Pharo PPA doesn't seem to work on ubuntu vivid (15.04)
Hello Javier, I copied the packages to Vivid, can you try again? Please also install pharo-sources Best regards, Markus Am 11.06.2015 um 15:54 schrieb Javier Pimás: Hi there, after adding the ppa to the system I cannot install the vm. Only pharo-launcher is available but it can't be installed because the pharo-vm-core-i386 is not installable. What I tried was this: sudo apt-add-repository ppa:pharo/stable sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install pharo-launcher looking at https://launchpad.net/~pharo/+archive/ubuntu/stable https://launchpad.net/%7Epharo/+archive/ubuntu/stable it seems like packages are too old (before 15.04 came out), maybe they need to be updated? cheers, Javier -- Javier Pimás Ciudad de Buenos Aires
Re: [Pharo-dev] Pharo PPA doesn't seem to work on ubuntu vivid (15.04)
Thanks! I now installs just fine, and everything works correctly after also installing pharo-source-files On Thu, Jun 11, 2015 at 4:08 PM, Markus Fritsche mfrits...@reauktion.de wrote: Hello Javier, I copied the packages to Vivid, can you try again? Please also install pharo-sources Best regards, Markus Am 11.06.2015 um 15:54 schrieb Javier Pimás: Hi there, after adding the ppa to the system I cannot install the vm. Only pharo-launcher is available but it can't be installed because the pharo-vm-core-i386 is not installable. What I tried was this: sudo apt-add-repository ppa:pharo/stable sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install pharo-launcher looking at https://launchpad.net/~pharo/+archive/ubuntu/stable https://launchpad.net/%7Epharo/+archive/ubuntu/stable it seems like packages are too old (before 15.04 came out), maybe they need to be updated? cheers, Javier -- Javier Pimás Ciudad de Buenos Aires -- Javier Pimás Ciudad de Buenos Aires
Re: [Pharo-dev] Detecting the context/producer of code change announcements
@Max: I watched the presentation but I'm not sure how to apply it in this case. (Last exam!? good!) @Ben: I agree that there are not only 2 levels, high-level and low-level announcements but a hierarchy. For example, a MCVersionLoad could have a MetacelloProjectLoad as a parent. @Chris (and all): Thanks for your feedback. I'm in for any solution that can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way. Before I didn't mention that I considered Job as a possible solution. Job represents a task to run. For example: [ :bar | bar increment. (Delay forSeconds: 1) wait. bar increment. (Delay forSeconds: 1) wait. ] asJob title: 'Loading'; min: 1; max: 3; run But, additionally to that basic function: - Each Job knows its parent. - Job class implements #current which looks up the next job in the execution stack (using Exception), or nil if none. The current (but fixable) limitation of Job is that it only holds a title string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated. MCVersionLoader load ... [ ... produce code changes ... ] asJob title: 'Loading'; description: (MCVersionLoad versionName: ...) run. MyListener classAdded: ... Job lookupParent: [ :job | job description isHighLevelOperation ] ifPresent: [ ... ] ifAbsent: [ ... ] Regards, Martin On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham cunningham...@gmail.com wrote: On Wed, Jun 10, 2015 at 11:29 AM, Max Leske maxle...@gmail.com wrote: On 10 Jun 2015, at 17:13, Martin Dias tinchod...@gmail.com wrote: Hi everybody, snip The other thing would be to clean up the announcer situation… Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if you’re interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer. I'm not sure how the hierarchical announcers would help Ben's issue (as I see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list) If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them. That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc). Just thoughts. -cbc I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max Kind regards, Martín
[Pharo-dev] Pharo PPA doesn't seem to work on ubuntu vivid (15.04)
Hi there, after adding the ppa to the system I cannot install the vm. Only pharo-launcher is available but it can't be installed because the pharo-vm-core-i386 is not installable. What I tried was this: sudo apt-add-repository ppa:pharo/stable sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install pharo-launcher looking at https://launchpad.net/~pharo/+archive/ubuntu/stable it seems like packages are too old (before 15.04 came out), maybe they need to be updated? cheers, Javier -- Javier Pimás Ciudad de Buenos Aires
Re: [Pharo-dev] Detecting the context/producer of code change announcements
Hi Martin, I believe your job example express better what you need, so what I would propose would be a notion of parent in the normal code announcements, containing, in a hierarchical way, the higher level context information. But implementing that parent in the announcements will be difficult, so I'd take either your job solution, or a notification (RequestContextNotification); the notification handler would then be able to provide the context when this notification is signaled (and, of course, this would be hierarchical). A pre/post announcement doesn't work: you cannot guarantee that things happening between those two belongs to this context because it may be done in different processes. Regards, Thierry Le 11 juin 2015 14:05, Martin Dias tinchod...@gmail.com a écrit : @Max: I watched the presentation but I'm not sure how to apply it in this case. (Last exam!? good!) @Ben: I agree that there are not only 2 levels, high-level and low-level announcements but a hierarchy. For example, a MCVersionLoad could have a MetacelloProjectLoad as a parent. @Chris (and all): Thanks for your feedback. I'm in for any solution that can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way. Before I didn't mention that I considered Job as a possible solution. Job represents a task to run. For example: [ :bar | bar increment. (Delay forSeconds: 1) wait. bar increment. (Delay forSeconds: 1) wait. ] asJob title: 'Loading'; min: 1; max: 3; run But, additionally to that basic function: - Each Job knows its parent. - Job class implements #current which looks up the next job in the execution stack (using Exception), or nil if none. The current (but fixable) limitation of Job is that it only holds a title string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated. MCVersionLoader load ... [ ... produce code changes ... ] asJob title: 'Loading'; description: (MCVersionLoad versionName: ...) run. MyListener classAdded: ... Job lookupParent: [ :job | job description isHighLevelOperation ] ifPresent: [ ... ] ifAbsent: [ ... ] Regards, Martin On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham cunningham...@gmail.com wrote: On Wed, Jun 10, 2015 at 11:29 AM, Max Leske maxle...@gmail.com wrote: On 10 Jun 2015, at 17:13, Martin Dias tinchod...@gmail.com wrote: Hi everybody, snip The other thing would be to clean up the announcer situation… Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if you’re interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer. I'm not sure how the hierarchical announcers would help Ben's issue (as I see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list) If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them. That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc). Just thoughts. -cbc I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max Kind regards, Martín
Re: [Pharo-dev] Pratt Parsers for PetitParser
That sounds really cool and useful extension. Regarding the furthest failure, the core of the problem is the distinction between an error and a failure. Error reports on a problem in the input, while failure is information for choice parser combinator. In general, the furthest failure is a better approximation of an error than the last failure, so we use it. I am not sure what exactly is the problem in case of PrattParser. I guess the last failure gives better results for a user? One has to consider a pratt parser included in the normal parser, e. g. Expressions parsed by pratt in a Java Grammar. Depending where an error occurs, different strategy for choosing the proper failure is necessary :-/ Regarding tokenization, there is a message token, that returns PPTokenParser, which transforms a parsed input into the PPToken object. Perhaps this might be helpful? Cheers Jan On Wed, Jun 10, 2015, 20:52 Richard Sargent richard.sarg...@gemtalksystems.com wrote: camille teruel wrote On 10 Jun 2015, at 19:11, Chris Cunningham lt; cunningham.cb@ gt; wrote: Inteteresting On Wed, Jun 10, 2015 at 9:36 AM, Camille lt; camille.teruel@ lt;mailto: camille.teruel@ gt; wrote: Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. snip @PP Devs: I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). But I guess it was introduced because it gives good results in other cases. So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? The intent behind the furthestFailure is that it give the failure that gets the furthest into the source stream. It is most useful when there are embedded choice operators in the parser - the original/pre furthest behaviour would return the last failure, which depending on the incoming stream and the order of the choice options could be significantly not useful. I ran into this when working with the sql parser, which started off with the outer choice of (by memory): ^ selectStatement / insertStatement / updateStatement / deleteStatement If I was trying to part a select statement that had an error at the very end of the statement, the parser would return an error talking about how the incoming stream failed in deleteStatement. Not useful. I would be saddened if this further failure was not available. Yes in that case returning the furthest failure gives better results. However, this don’t give meaningful messages in all cases. For exemple with the calculator I gave in my previous message, if I parse ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns ‘$- expected at 2'. I’m not proposing to remove this feature but to let parsers decide to use it or not. Something like (changes in bold): PPParserparseWithContext: context | result | context initializeFor: self. result := self parseOn: context. Return the furthest failure, it gives better results than the last failure (result isPetitFailure and: [ self wantsFurthestFailure and: [ context furthestFailure notNil ] ]) ifTrue: [ ^ context furthestFailure ]. ^ result This screams at me. Why not just delegate to the context and use a context that returns the preferred failure? e.g. end with: ^context preferredResultFor: result. PPParserwantsFurthestFailure ^ true Like this, one can return the failures he wants. PPPrattParserwantsFurthestFailure ^ false Camille -cbc -- View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Pratt Parsers for PetitParser
On 10 Jun 2015, at 20:31, Richard Sargent richard.sarg...@gemtalksystems.com wrote: camille teruel wrote On 10 Jun 2015, at 19:11, Chris Cunningham lt; cunningham.cb@ gt; wrote: Inteteresting On Wed, Jun 10, 2015 at 9:36 AM, Camille lt; camille.teruel@ lt;mailto: camille.teruel@ gt; wrote: Hello Pharoers and Moosers, I did a Pratt parser extension for PetitParser. snip @PP Devs: I had trouble with the PPContext furthestFailure that is taken into account instead of the failures I return, so I had to redefine #parseWithContext: to return the failures I want. The results given by furthestFailure were not very meaningful in my case (the same is true for PPExpressionParser btw). But I guess it was introduced because it gives good results in other cases. So would it be possible to change this behavior to let the parser decide if it returns the furthestFailure or the original failure? The intent behind the furthestFailure is that it give the failure that gets the furthest into the source stream. It is most useful when there are embedded choice operators in the parser - the original/pre furthest behaviour would return the last failure, which depending on the incoming stream and the order of the choice options could be significantly not useful. I ran into this when working with the sql parser, which started off with the outer choice of (by memory): ^ selectStatement / insertStatement / updateStatement / deleteStatement If I was trying to part a select statement that had an error at the very end of the statement, the parser would return an error talking about how the incoming stream failed in deleteStatement. Not useful. I would be saddened if this further failure was not available. Yes in that case returning the furthest failure gives better results. However, this don’t give meaningful messages in all cases. For exemple with the calculator I gave in my previous message, if I parse ‘1+’ I want to get ‘expression expected at: 2’ but instead it returns ‘$- expected at 2'. I’m not proposing to remove this feature but to let parsers decide to use it or not. Something like (changes in bold): PPParserparseWithContext: context | result | context initializeFor: self. result := self parseOn: context. Return the furthest failure, it gives better results than the last failure (result isPetitFailure and: [ self wantsFurthestFailure and: [ context furthestFailure notNil ] ]) ifTrue: [ ^ context furthestFailure ]. ^ result This screams at me. Why not just delegate to the context and use a context that returns the preferred failure? e.g. end with: ^context preferredResultFor: result. Because the same context is passed around by many parsers. So if you let the context decide, you get the same behavior for all the parsers. PPParserwantsFurthestFailure ^ true Like this, one can return the failures he wants. PPPrattParserwantsFurthestFailure ^ false Camille -cbc -- View this message in context: http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html http://forum.world.st/Pratt-Parsers-for-PetitParser-tp4831456p4831486.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com http://nabble.com/.
Re: [Pharo-dev] Pharo 4, format on accept/display
Date: Thu, 11 Jun 2015 08:35:10 +0200 From: steph...@free.fr To: pharo-dev@lists.pharo.org Subject: Re: [Pharo-dev] Pharo 4, format on accept/display Le 10/6/15 20:47, Paul DeBruicker a écrit : Hi I've hacked together an implementation of format on accept display. I know someone is redoing that functionality to better suit future needs. Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? Yes it is cool :) :) new text editor new pretty printer :) print on read print on accept :) Hi, We are working on a new pretty printer and using rubric in Nautilus for the source code area so you will soon be able to format on accept but not only. A format as you read feature will be introduce, if you activate it, it will format the source code with your own preferences every time you read code, and every time you accept. Franck Thanks Paul
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
Really cool! About the spotter integration, it is really nice to be able to search and find new projects like this. Well done. But, there are two things that I would change: - Right now, the processor order is 10. If you search for GTSpotter, you will get the catalog project before the class: [image: Inline image 1] I would rather prefer the order to be next to the Metacello configurations, so I would make it 90. The reason is that the things that are in the image should take precedence because they are much more often used. - For the preview, I would put the details that we have about the project. - Also, if you are at it, it would be nice to add an inspector extension for showing all projects of a CatalogProvider and to add a load action for a CatalogProject object :) Cheers, Doru On Thu, Jun 11, 2015 at 8:55 AM, Torsten Bergmann asta...@gmx.de wrote: Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. What to do next: - give feedback - we should update all our configs with catalog descriptions - it would be nice if the spotter integration would include also a preview of the project description - ... If you want to contribute just tell Esteban so he can add you to the project. Thanks Esteban Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964.html [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/json -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Pharo 4, format on accept/display
On 11 Jun 2015, at 08:16, Peter Uhnák i.uh...@gmail.com wrote: If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. Yes, but we do make exceptions… e.g. I added format on display and accept to Pharo3 after the release, because it is indeed a nice thing to have. So in that sense not having it in Pharo4 is kind of a bug. The version we get in Pharo5 will come with a new pretty printer, we will not back port that, so doing a “minimally intrusive” version for Pharo4 makes sense. Marcus
Re: [Pharo-dev] Pharo 4, format on accept/display
If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. So from this perspective I would suggest to publish it to Pharo50Inbox instead, including creating a new issue in Pharo bugtracker where you describe what is it changing. If you need in Pharo 4 it may be preferable to create a new repository for it (at smalltalkhub) and pushing it's configuration to http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo40, so people can install it manually via Configuration Browser without affecting Pharo 4 release. Peter On Thu, Jun 11, 2015 at 7:25 AM, Ben Coman b...@openinworld.com wrote: By publish a slice do you also mean to ask it to be integrated into Pharo4? The general issue is that every new fix for the released Pharo40 has the *chance* of introducing some other problem, or adversely affecting someone else's idea of how the system should operate. Even with minimal quaility assurance for a release it takes effort to integrate fixes, so each needs to be evaluated for impact. So the options for Pharo 4 are: 1. Continually integrate fixes as they arise == ++effort 2. Continually integrate critical fixes only, hold all others for the next point release. 3. Hold all fixes for next point release. I don't see this as a critical fix :), so you'd be asking for (1.), when probably (2.) should be the rule. Now I had the idea that fixes for a release that were not immediately integrated might be published as a hotfix - taking Microsoft's terminology for an update fixing a specific issue without having gone through full quality control with all other fixes, so kind of use at own risk. I'm not sure if that was popular or the best way to go about it. Possibly just adding hotfix in the mcz file name would provide enough to find them by filtering. cheers -ben On Thu, Jun 11, 2015 at 2:47 AM, Paul DeBruicker pdebr...@gmail.com wrote: Hi I've hacked together an implementation of format on accept display. I know someone is redoing that functionality to better suit future needs. Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? Thanks Paul
Re: [Pharo-dev] Pharo 4, format on accept/display
Le 10/6/15 20:47, Paul DeBruicker a écrit : Hi I've hacked together an implementation of format on accept display. I know someone is redoing that functionality to better suit future needs. Should I publish what I've got as a slice to the Pharo40Inbox for people to use that may miss it now that do not want to wait for the new hotness? Yes it is cool :) :) new text editor new pretty printer :) print on read print on accept :) Thanks Paul
[Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. What to do next: - give feedback - we should update all our configs with catalog descriptions - it would be nice if the spotter integration would include also a preview of the project description - ... If you want to contribute just tell Esteban so he can add you to the project. Thanks Esteban Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964.html [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/json
Re: [Pharo-dev] Pratt Parsers for PetitParser
On Jun 11, 2015, at 2:47 AM, Camille camille.ter...@gmail.com wrote: But furthest failure gives wrong messages in other cases to. Consider this sequence parser: keyword := #letter asParser plus , $: asParser. keyword parse: ‘foo' This returns 'letter expected at 3’, but no matter how many letters I add to the end I’ll still get ‘letter expected’. I want to get what is really missing: '$: expected at 3’. Indeed. I recently submitted an update to the parser and tests (based on code from Dale Henrichs) for a problem in which trim would cause the error to always be “separator expected” when there was something after the separator that was expected. Better error reporting would certainly be helpful. The ‘letter expected’ explanation is quite wrong. James Foster
Re: [Pharo-dev] Probably Metacello sucks…
Absence of Metacello won't help you dealing with dependencies and loading stuff by using hand-made scripts by dozens of people written at different points in time and not maintained by anyone. It may be too complicated to use, especially at earlier stages of development, and in situations, when all you need is to use latest versions of everything available (aka #bleedingedge). But always staying on bleeding edge hurts a lot (that's why it called so) and it is conscious choice of many professional developers to base own development on latest but stable versions of dependencies. Simply because then you have more time focusing on what you want to do, instead of fighting with various bugs and drastic changes and updates in numerous dependencies. And this is where tools like Metacello helping a lot. Because once you define stable point, you can always be sure that you can reproduce it at any moment and load without problems. And no, script on which you spent 1 minute and placed on pastebin doesn't helps in such situation. It just contributes even more mess to what is already there. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo 4, format on accept/display
Format on display does horrible things to the Playground for the version I uploaded yesterday. A new version is in the inbox that does not do them. Marcus Denker-4 wrote Thanks, I will have a look. On 11 Jun 2015, at 16:39, Paul DeBruicker lt; pdebruic@ gt; wrote: The 'fix' for Pharo40 is in the Pharo40Inbox as Slice-14387. It formats code on accept and/or display using the RBConfigurableFormatter. Marcus Denker-4 wrote On 11 Jun 2015, at 08:16, Peter Uhnák lt; i.uhnak@ gt; wrote: If my understanding of Pharo's release management is correct, then no new features are added after a release, only bugfixes. Yes, but we do make exceptions… e.g. I added format on display and accept to Pharo3 after the release, because it is indeed a nice thing to have. So in that sense not having it in Pharo4 is kind of a bug. The version we get in Pharo5 will come with a new pretty printer, we will not back port that, so doing a “minimally intrusive” version for Pharo4 makes sense. Marcus -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831720.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Pharo-4-format-on-accept-display-tp4831485p4831805.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] What CodeImport is all about?
Hi! I cannot figure out what this package is about. Looks like a kind of change set? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Probably Metacello sucks…
Le 11 juin 2015 à 07:52, Yuriy Tymchuk a écrit : Once Stef mentioned that there is some project for dependency checking. What was it? Maybe we can use that? http://smalltalkhub.com/#!/~PharoExtras/Tool-DependencyAnalyser But take care, it only spots static dependencies (inheritance, reference, extensions, traits). smime.p7s Description: S/MIME cryptographic signature
[Pharo-dev] [pharo-project/pharo-core] 8d0d4b: 50104
Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8d0d4b83a51fc2534b07dc6a7b56038f792cc62f https://github.com/pharo-project/pharo-core/commit/8d0d4b83a51fc2534b07dc6a7b56038f792cc62f Author: Jenkins Build Server bo...@pharo-project.org Date: 2015-06-11 (Thu, 11 Jun 2015) Changed paths: A ProfStef-Core.package/AbstractTutorial.class/class/tutorial metainfo/contentsOfTutorials.st A ProfStef-Core.package/PharoTutorial.class/class/accessing/contents.st M ProfStef-Help.package/PharoTutorialHelp.class/class/pages/listOfTutorials.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50103.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50104.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50103.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50104.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 50104 15636 PharoTutorial contents https://pharo.fogbugz.com/f/cases/15636 15731 Kill the last two #asTimeStamp methods https://pharo.fogbugz.com/f/cases/15731 15734 More tests for reifications https://pharo.fogbugz.com/f/cases/15734 http://files.pharo.org/image/50/50104.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/50104 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] New Tool: Catalog Browser in Pharo 5.0
On 11 Jun 2015, at 16:42, Ben Coman b...@openinworld.com wrote: On Thu, Jun 11, 2015 at 2:55 PM, Torsten Bergmann asta...@gmx.de mailto:asta...@gmx.de wrote: Hi, maybe you already noticed. The latest update for Pharo 5 which is 50103 (see [1]). includes a new tool called Catalog Browser. Where to go === You will find it under Tools - Catalog Browser and it will display the configs together with the catalog metadata like project description. The code is managed with a configuration similar to what we have for a few other packages/projects. The tool was written by Esteban Lorenzano with small improvements like spotter integration from my side. Feel free to contribute more features. The repository can be found on SmalltalkHub [2]. This new tool basically gives you access to all available configurations aggregated at [3]. You can use a small UI to search and load the configs (see world menu - Tools - Catalog Browser. But you can also use Spotter to load a config. Example on how to load ScriptManager config: - open Spotter (SHIFT + ENTER on Windows, ...) - type in Script and you will find a spotter category Catalog Projects with ScriptManager in it - just hit enter and the config is loaded Just had a quick try. Its nice to get descriptions, like for TaskIT. However I think there should be a confirmation dialog before actually loading a Configuration, which is a potentially destructive/undoable action. Its too easy that habits pressing enter for other functions assert themselves and load a configuration accidentally. Perhaps an alternative is to open a window with more information from the other fields of the catalog that has a button to load the Configuration. Same for all others, so try with Seaside, MongoTalk, ... In the short/mid-term this new tool should replace the existing config browser as it gives more informations about the projects. I don't think its a total replacement for the Configuration Browser. The new function suits the case of searching for a configuration you already know about, bu tmany times I like catalog browsers when I'm not searching for something. That is, when I don't know what is there and I'm *browsing*. Indeed, if you are searching for a particular configuration then you probably already know what it is and the additional info is then not needed. But is a superset. We do not want to keep two tools with same functionality (we already did this a lot in the past, but we are like alcoholics in recovery now… :P) Esteban ps: when you already know what you want, most probably you just load through a command line (or a script)… at least that’s what I do :) cheers -ben What to do next: - give feedback - we should update all our configs with catalog descriptions - it would be nice if the spotter integration would include also a preview of the project description - ... If you want to contribute just tell Esteban so he can add you to the project. Thanks Esteban Torsten [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-June/110964.html [2] http://www.smalltalkhub.com/#!/~estebanlm/CatalogBrowser [3] http://catalog.pharo.org/catalog/json
Re: [Pharo-dev] Detecting the context/producer of code change announcements
2015-06-11 16:49 GMT+02:00 Ben Coman b...@openinworld.com: Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children. The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement. Another issue is, when introducing a new class of activity such as SprintInRMOD, you then need to rewrite all the listeners to add the relevant: ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ] Kind of messy. For me, what Martin is trying to do is currently handled in a way by MC and RB: write all your code operations as abstract operations on a model of the code, group them into a composite (RBCompositeChange or something like that), and apply them all in one go. But all this structure is flattened in the change set, and may be interleaved with other changes happening at the same time. I'd take Martin's job idea :) plus specific announcements for the start and end. Thierry cheers -ben I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max Kind regards, Martín
