Re: [Pharo-users] Updating singletons
--- Begin Message --- Dale, > This looks like a case where you are using a metadata-less repository > ... if so you, should add the following method to your baseline class: Sorry, that's way above my understanding of baselines and repository handling in general. I started from https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md and adapted the examples there to my own situation, my project being hosted on GitHub: https://github.com/khinsen/leibniz-pharo/ > This mod will cause packages to be unconditionally loaded ... Monticello > does a definition comparison on package load so only changed definitions > are loaded into the image ... I'd say that a new dependency should be treated like a changed one, but again I am still very much lost in the jungle of Monticello, Metacello, Gofer, Iceberg, etc. It's the most opaque aspect of Pharo I have encountered so far. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] Updating singletons
--- Begin Message --- H Cyril, > Fetching, loading and post loads should leave a trace during the > execution in the Transcript. Thanks, that helps to confirm that my postload is never executed when I update a package + baseline in an image that already had an earlier version loaded. Nothing at all is shown in the Transcript. Reloading the package and/or the baseline package doesn't leave any trace either. And if I add a dependency, then update the package again, the new dependency is not loaded either. Hypothesis: baseline changes have no effect for already installed packages. When I load my modified package + baseline into a fresh image, lots of actions are shown in the Transcript, including the execution of my postload action. But in that situation, I don't actually need it. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] Updating singletons
--- Begin Message --- Ben, > You might use a Baseline #postLoadDoIt: > https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md Thanks, that looks like exactly what I need... except that it doesn't seem to work. My postload method is not run when a new version of the code is loaded into an image. Nor when I load my project into a fresh image. Which makes me wonder more generally how one can debug baselines. The mechanism that uses them is very opaque: you write some code as a kind of plugin to some framework, but it is not clear at all how this code is used. > Consider that a person pulling your changes cannot know if you have > upgraded the library versions of any dependencies, > so always updating via a Baseline might be a reasonable expectation. Indeed, baselines make a lot of sense in principle. Cheers, Konrad --- End Message ---
[Pharo-users] Updating singletons
--- Begin Message --- Dear Pharo experts, I am wondering if there is a good way to deal with singleton objects whose value needs to be updated following changes in the code that initializes it. Following the model of many examples in Pharo itself, I have defined a singleton class with a uniqueInstance method for accessing (and creating if necessary) the single instance, and a method "reset" marked as a script to set the uniqueInstance back to nil when required, i.e. after source code changes make the prior value inappropriate. This works very well, as long as I don't forget to do the reset, which has already caused me a few hours of debugging time. Worse, suppose someone else is using my project in progress, pulling changes from my GitHub repo once per week. That person cannot know if the latest changes require a singleton reset. More importantly, users shouldn't have to know about such internal details at all. So is there a way to do the reset automatically whenever a new version of my package is loaded into an image? Thanks in advance, Konrad. --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- Hi Doru and Offray, Tudor Girba via Pharo-users writes: > A separate editor is needed when the markup has little resemblance > with the output, which is the case for HTML. In this case, > bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very > nice thing. Or when the output reflects only a part of the input document. I suspect Offray has the same kind of application in mind as myself, knowing a bit of his work, and it is indeed a bit different from what you are designing GT for. What we do (mainly) is documenting computations, not software. A computation consists of code, input data, and selected results. This inevitably requires some metadata that needs to be editable but should not necessarily appear in the output. The most basic technology for documenting computations is the notebook (Mathematica, Jupyter, ...) where the metadata is just the cell structure (which does show in the output). More sophisticated systems (Emacs OrgMode for example) allow more fine-tuning, making for much nicer output, but also requiring quite a bit more metadata. > However, in the case of Documenter and the Pillar markup the output is > closely related to the sources part. In this case, having the two >From what I know about Pillar, I agree. The way this is handled in Documenter is indeed very appropriate for very simple markup like that. And simple markup is highly desirable whenever sufficient. > worlds be supported seamlessly in the same experience is a huge > advantage, especially for non-technical people. The interface from > Documenter is not trivially possible (I for now never saw one like > that, and I looked specifically for it) because of the prerequisites The closest I have seen is MarkText: https://marktext.github.io/website/ Its "focus mode" works much like Documenter in principle, but feels less fluent somehow. Offray Vladimir Luna Cárdenas via Pharo-users writes: > but is not their only concern. ATM seems that new GT is pretty tied to > Pillar and software documentation (which is fine, but not the path I'm > primarily interested). Me neither, but I still find a lot of interesting ideas in GT and I suspect that a tool closer to my interests could be built with reasonable effort from the bricks that GT provides. My holy grail is a document that describes both software and computations, combining the features of notebooks and literate programming into a hypertext-like system in which I can start at the surface (the computation) and "zoom in" to any part of the software, getting documentation and not just source code. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] (no subject)
--- Begin Message --- Offray, > It's really nice to have you hear. I remember some of our Twitter Thanks for the welcome! > I restarted with Pharo in 2014, after a short revealing experience with > Squeak, EToys and Bots Inc in 2006-2007 and now I'm enjoying the Joyride[1] > > [1] https://twitter.com/offrayLC/status/493979407011561473 Nice :-) I guess the tough part is figuring out where you are on that curve! Konrad. --- End Message ---
Re: [Pharo-users] (no subject)
--- Begin Message --- Thanks to everyone who replied - the sum of the answers is actually a lot more useful than each one individually, as each one points to a part of the puzzle that Pharo is (for me, at least, after roughly one month of use). Ben Coman writes: > This may not be what you are looking for, but maybe help flesh out ideas. > Try debugging... > OpalCompiler new evaluate: '1 + 2' An interesting experience indeed! Tim Mackinnon writes: > I was going to chip in that every class inherits what compiler it > uses and so you can easily override that to do something special > (like wrapping classes). An interesting feature, though it seems a bit too low-level for my project, and definitely too low-level for my current Pharo competence. > However, is this possibly an area where the meta-links kicks in so > you don’t have to do this and get a more generic solution? (I haven’t > played with this, but there are a few threads where people are using > it, and it’s progressed quite a lot in Pharo 7). That sent me off research meta-links: https://pharoweekly.wordpress.com/2018/03/27/understanding-metalinks/ Interesting stuff as well, but the same comment applies: this looks too low-level for what I consider boring code implementing routine techniques. Steffen Märcker via Pharo-users writes: > Did you already try to measure the impaired overhead of a wrapper > solution? It might very well be negligible in an otherwise purely > symbolic computation. I did not look into performance questions at all for now. What scares me most is the overhead in code size, in particular in my test suite. > A hybrid solution might be - instead of wrapping each value - to add a > single method to the value classes that wraps a value on the fly if > needed, e.g. > > Integer>>asExpression >^ExpressionWrapper wrap: self. That looks like an interesting compromise, and one that I have seen used elsewhere. > Another option might be to build a trait that adds the behavior to the > value classes. A nice suggestion as well - I haven't looked at traits yet in any detail. Serge Stinckwich writes: > in your case I would write a parser for your specific concrete syntax > with PetitParser and then generate an instance of the abstract syntax > you have defined. My first reaction was that this looks like overkill for my problem. But then, considering that I will eventually need a parser anyway, why not start that way and use it in my own test cases? A path worth exploring. Thanks again to everyone - your comments will keep me busy for a while! Konrad. --- End Message ---
