Hi all,
I have some time to fix QCMagritte, and wanted to make it work for the latest Pharo and to my surprise, loading Magritte itself is broken for Pharo 7. If I understand correctly the official project on GitHub is in the project https://github.com/magritte-metamodel There are only 2 people in this repository. Sean or Cyril, can you add me (delware // [hidden email]) to this repository so I can make Magritte working again? Cheers, Diego _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Le 14/05/2019 à 13:13, Diego Lont a écrit :
> Hi all, > > I have some time to fix QCMagritte, and wanted to make it work for the > latest Pharo and to my surprise, loading Magritte itself is broken for > Pharo 7. > > If I understand correctly the official project on GitHub is in the > project https://github.com/magritte-metamodel > There are only 2 people in this repository. Sean or Cyril, can you add > me (delware // [hidden email] <mailto:[hidden email]>) to > this repository so I can make Magritte working again? > Done > Cheers, > Diego > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.list.inf.unibe.ch/listinfo/smallwiki > -- Cyril Ferlicot https://ferlicot.fr _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki signature.asc (836 bytes) Download Attachment |
In reply to this post by DiegoLont
Done
Norbert
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi all,
Thanks for the fast actions. It appeared that the problem was the explicit version in the Magritte Configuration to an old Seaside version. This Seaside version did not have any definitions for Pharo6 and Pharo7, and therefor gave errors on loading. I committed the change, removing the version reference to the Seaside repo, and now I have now a working Pharo 7 image again with Magritte. I can load this again with: Metacello new githubUser: ‘Magritte-metauser' project: 'Magritte' commitish: 'master' path: 'source'; baseline: 'Magritte'; load: #( ’Seaside’ ) I guess we now need to change this in Pharo 7, that the configuration points to the withub instead of Smalltalkhub. I will test more extensively tomorrow. Regards, Diego
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi Diego,
I reverted that change. I don’t think is good to take an actual problem and just make heavy changes like this to fix it. There are more people using the repo. Can you explain what problem you encounter exactly. Maybe we find another solution to fix it. Norbert
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi all,
Ok, my problem is that when I try to load Magritte-Seaside into a fresh Pharo 7 image this fails. I had to get back into Pharo and the tools that I could use to analyse this problem, and here is the things that I found: - Loading it from the Pharo loader resulted in loading it from Smalltalkhub, and although it did not gave any errors: it did not result in a working version - Loading it from GitHub resulted in an error: ’Seaside-Pharo-Development’ not found. For this I used a fresh Pharo-7 image (the Pharo loader works terrific by the way) and executed following code:
I believe this should work. But it does not. To be specific here: this is because the version of Seaside that is referred here, does not contain any definitions for Pharo6. Therefor it cannot find the generic include for Pharo that is done to Seaside-Pharo-Development for Seaside-Pharo-Development-Test. And since this is a tag, and not a branch, it is not so easy to fix, because it is more or less frozen. - Maybe this last point is a bit academic: The configuration of Magritte on GitHub referred to a fixed version of Seaside and Grease, but since Seaside only has tags, and does refer to master, this also gives a conflict in versions … I must admit I was a bit fed up, that things just did not work out of the box (terrible pr by the way). So maybe was a bit too fast in “just fixing” the problem. I am sorry for that. I will write a separate mail about what I believe is the right way, and first discuss the configuration management problem, before making other changes to the configuration. For now I will revert to using a clone on my own repository and be able to load it using this. Cheers, Diego
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi Diego,
try again it should work now. I do not really get all the „analysis“ you did when the solution is just to raise the version number of the seaside dependency in Magritte-Seaside. That is all I did (well I just merged a pull request from Cyril). The obvious analysis is that grease and seaside are used because pharo7 is supported there. And yes, nobody seems to use Magritte-Seaside in pharo7. You said you found it annoying that it did not work out of the box. And it is a bad PR. Well, nowadays there seem to be too many people talking about PR and nobody does to work. And to be honest the change you did was the best assurance that the next one trying does not succeed. And you are not a first-timer here. Me, a little bit fed up myself, Norbert
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi norbert,
I am very sorry that I added negative vibes. As I wrote earlier, I was too fast in checking in the “fix”. Thank you and Cyril for taking time to fix the configuration. Regards, Diego
Unfortunately I still get an error that it cannot load, because now the reference to grease is incompatible. The exact error I get is: Load Conflict between existing BaselineOfGrease [baseline] from <a href="github://SeasideSt/Grease:v1.4.2/repository" class="">github://SeasideSt/Grease:v1.4.2/repository and BaselineOfGrease [baseline] from <a href="github://SeasideSt/Grease:master/repository" class="">github://SeasideSt/Grease:master/repository So I am afraid that the fix is not simply updating the versions. But when I am the only one wanting to use Magritte-Seaside under Pharo 7, I am fine with my own fork. I guess that is one of the advantages of GitHub.
To name a few of my favourites so far: - I notice the VM is a lot more stable (I did some stupid things, but still my image did not crash) - being able to set breakpoints is very nice - the inspector is really good, so I did not need to revive Metaceller to analyse the configurations…
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Hi Diego, you‘re welcome. It is not a desired state if it does not work. But a positive attitude usually has better chance of pushing things forward. There were also more than your reactions which I found annoying. Anyway I think that release problem is really hard. We have a situation where magritte depends on grease and seaside depends on grease. Then Magritte-Seaside depends on magritte and seaside so this is an unfortunate situation. And I think Magritte-Seaside should be moved to the seaside organization (https://github.com/SeasideSt) . Baselines IMHO are better pointing downwards the dependency tree. So if there would be a BaselineOfMagritteSeaside it would just point to its dependencies. Norbert
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
In reply to this post by DiegoLont
Just now saw the rest of the email. Try loading Metacello new repository: ‚github://magritte-metamodel/magritte‘; baseline: #Magritte; onConflictUseIncoming; load: ‚Seaside‘
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
I wonder if the concept of peer dependencies would not help us out.
Obviously, they need to be adder to metacello first... https://blog.angularindepth.com/npm-peer-dependencies-f843f3ac4e7f Cheers Johan
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Looking at the article makes me think that peer dependencies are equivalent to project attributes (common, gemstone, pharo, pharo7.x, etc.) and Metacello already has hooks for adding custom platform attributes ... see the method ConfigurationOf>>customProjectAttributes and then look at implementors for a couple of examples ... Everything with the #custom block would "be compatible with" your custom thing, just like you declare that a set of packages are compatible with Pharo 7.x. Dale On 5/17/19 11:29 AM, Johan Brichau
wrote:
I wonder if the concept of peer dependencies would not help us out. _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
In reply to this post by Johan Brichau-3
Wouldn‘t we need the possibility to load two versions of a code base into the same image? Norbert
_______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
Free forum by Nabble | Edit this page |