Re: Minheadless trial
Locked
 
|
Hi Ben,
Sorry for coming here so late, I didn’t see this thread before. I already have a working minheadless branch that was adapted to Eliot’s process. It was working for Pharo in Linux and Mac (Windows was ongoing but not finished, that’s why is not pushed). You can find this branch here: Interesting part is that I didn’t tackled any of the issues you are working on, so the work is easily mergeable :) Cheers, Esteban Ps: with some changes in image, I’m using exclusively this VM since a couple of months and it works fine.
|
|
|
What keeps you from doing a pull request to opensmalltalk-vm ?
|
|
|
I’m slowly working on that VM because we want it to be the default for Pharo 8.
In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. To make this work, we need all platforms covered (and another huge quantity of changes here and there). Anyway, I didn’t merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didn’t feel pression to do it :) Cheers, Esteban
|
|
|
Guys - do keep pushing on this - I think its quite important in this world of serverless… it shows we are very relevant. +10
|
|
|
In reply to this post by EstebanLM
Hi,
Yes, using SDL2 and OSWindow (with some modifications). Advantages of Pharo investment on this, even in things that seemed useless at the beginning ;) Also, the minheadless VM has a “traditional display” flag that will start a word too.
Yes, I like what Ronie did there, even if there is still work to do, but is cool.
It depends, but this is one of the reasons why we want to move into it. Our strategy is let the less possible in the VM (ideally, just the “core” VM and a great FFI support), and move all the rest into the image. Esteban
|
|
|
In reply to this post by EstebanLM
Hi Esteban,
|
|
|
Hi Eliot,
This is old thing (there is a pull request now, since like 3 weeks). I worked on my fork because that’s how you do it with git: you fork, you work, and you do a Pull Request when ready. I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it. I guess the terminology is confusing you? Cheers! Esteban
|
|
|
On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <[hidden email]> wrote:
I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk account", because any other branch is no different to any other branch regardless of which account its stored in. The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here.
On the flip side, release early release is a good policy. It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks. I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable submitting it to the mainline Cog branch.
That doesn't help. cheers -ben |
|
|
That’s not how you work on git/github and I prefer to keep it “as intended”.
Yeah, but for that you need to have something that you can release. minheadless was developed by Ronie (I just made the makefiles and adapted to build pharovms). And then it stalled around until I decided to took it and merge it… I’m going to be susceptible and say that frankly I do not understand the tone of this mails.
And I’m grateful :)
Why? Terminology *is* confusing, at least for me. Esteban
|
|
|
On Wed, 5 Dec 2018 at 23:29, Esteban Lorenzano <[hidden email]> wrote:
It came across sarcastic. My apologies. Email is a poor medium sometimes. cheers -ben |
|
|
In reply to this post by EstebanLM
Hi Esteban,
On Wed, Dec 5, 2018 at 5:53 AM Esteban Lorenzano <[hidden email]> wrote:
Ah, OK. I should;d have checked the dates more carefully.
I hope you forked opensmalltalk-vm not pharo-vm/opensmalltalk-vm, that's all.
I get forking in a single repository. I also get forking across repositories. These are two different things. I had misunderstood where you were forking. I apologize.
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by EstebanLM
Hi Esteban, Ronie, Forking, branching and merging is certainly the clean way to do it! The question is about the frequency of merges. Like Ben I prefer short cycles, because otherwise we just can't review the code, it' too many diffs at once. We can just trust, or not, take it or leave it... So who is going to take the responsibility? How i did it for win64 support? The canonicle way would have been to develop a long branch with hundreds of changed files/lines, then merge when ready. Instead of that, i integrated small batches of changes, none of which were sufficient to have win64 working, but none of which completely broke the trunk. Small steps... I know some purists that don't like my way of doing because we obtain interleaved features in the history preventing to easily bissect regressions, but i don't like puritanism either :). In fact, i did experiment like Ronie in my own private fork, then when ready, (not when perfect, but just when it reached a minimum of usability), i redone everything in smaller steps (cherry pick, rebase, squash, whatever...). I did also commit some changes in trunk, or accepted my own merge, which is questionable, but IMO more acceptable than rotting PR: that just means that i have to assume the responsibility of changes, I break it, I repair it. Ronie, you could adopt such strategy too, because in some aspects of the VM, you are the expert :)! It's certainly easier to concentrate on own changes and forget about the drag of legacy, but it's only a short term view. The burden of integration is differed, not eliminated, and the impact of changes not really mastered, because at the end we say let's integrate now and see later what is broken... We cannot always avoid such strategy when legacy code is too much intricated... But in this case, my own view of refactoring is untwist first, then replace. I don't want to discourage good will, on the contrary, thanks a lot for taking the burden of these essential changes!!! I rather want to encourage more frequent refactorings. Don't hesitate to flood opensmalltalk with small PR. They don't need to be perfect nor complete, as long as they go in the right direction. Smaller changes means less burden and less responsibility for the integrators, so more people can effectively integrate, not just Eliot or Ben. Cheers and thanks again! Le 5 déc. 2018 16:29, "Esteban Lorenzano" <[hidden email]> a écrit :
|
|
|
On Thu, 6 Dec 2018 at 01:25, Nicolas Cellier <[hidden email]> wrote:
An enlightening moment for me was reading an article about how PRs should not just be for the final product to integrate, but also be used heavily for discussion. Just put prepend something like "WIP" to the title. Then the PR is updated every time you commit to your source branch. There is even a github app to help manage that... The "compare" tool is then available to draw attention to particular changes between particular commits... cheers -ben
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |