[Pharo-dev] Refactorings/code rewriting
When creating Spec2 presenters, I noticed the automated refactorings (create accessors) don't all work. Do we need changes to the slots, or to the rewrite rules there? Stephan
Re: [Pharo-dev] [Esug-list] looking for input for a lecture on TDD and XtremeTDD
Hi Stef, I’ve done some workshops and screencasts. In the workshops (oops, already a few years ago) I used a morph that was moving on the screen to emphasize the liveness. The BabyMock2 work by Attila Magyar is also great for that. It also is good to show the difference between Chicago and London style TDD, and connect to BDD. In Smalltalk, that is more represented by the exploratory modeling I was introduced to by Rob Vens. https://www.reflektis.nl/blog/exploratory-modelling-explained/ For a lecture TDD as if you meant is is a good starting point: https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/ GToolkit of course provides some nice example-driven development, that combines well with literate programming In my latest screencasts I ran into the following issues: - restarting a test does not make it green after going through it if it needed a fix - can’t step into simple accessors (and other optimized code?) - in addition to create, need to be able to create/change setUp/initialize/shutDown - a refactoring ‘turn fake into class’ is missing where instVar := self and there are methods categorized as ‘faking instVar’ https://vimeo.com/329317634 https://vimeo.com/329368348 Stephan Verstuurd vanaf mijn iPhone > Op 14 apr. 2020 om 14:36 heeft Stéphane Ducasse > het volgende geschreven: > > Hello > > I would like to build a lecture around TDD and XtremeTDD (coding in the > debugger). > I’m looking around to see if someone already did such a lecture. > > S. > > Stéphane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > ___ > Esug-list mailing list > esug-l...@lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Re: [Pharo-dev] Are people using the Pharo VM builds from BinTray?
David T. Lewis wrote: > Is anyone using the Pharo VMs from BinTray? Otherwise if it's not a problem > for any Pharo users, I think the CI proprietors would like to turn off > some of their unnecessary builds to save resources. My understanding is > that the builds can easily be turned back on as needed in the future. I use them once in a while. Useful when triangulating issues Stephan
Re: [Pharo-dev] DrTest - strange UI effect and some feedback
Julien Delplanque wrote: > For the "Select none" I am not sure that we want to support that action > because it feels a bit odd. Why would one want to have nothing selected? > But if one can justify why this is needed, we can add it of course. > > "Select inversion" could be added but again I think this is a bit odd > feature. If you support select all you need at least one of invert selection and select none. All actions are supposed to be reversible as far as possible. Stephan
Re: [Pharo-dev] Antlr4 + SmaCC
Nicolas Anquetil wrote: > On Thu, 2019-10-03 at 11:54 +0200, Santiago Bragagnolo wrote: >> Hi there! >> I am trying to build a parser for visual basic. For doing so i found >> the Antlr definition of VB on the microsoft site. > > I tried with fortran and the answer was: Not so easy. > But then again, Fortran predates the theory of languages and it was not > defined to be easily parseable with a formal grammar. On the other hand, you know that you can parse these kinds of languages with 16K of ram, one 80 character line at a time. Stephan
Re: [Pharo-dev] Difficulty to use Iceberg
Jan Vrany wrote: > Hi, > > I'm experiencing difficulties (code loss, even) when trying to > commit code using Iceberg. > > I have a project with consist of some Pharo code and some > C++ code. Both parts kind of depend on each other. >... > Any suggestions? https://github.com/jecisc/GitBridge might be of help here Stephan
Re: [Pharo-dev] Pharo VM still crashing on Windows due to SSL
wrote: > Since my last post, Pharo is still crashing during installation of > Seaside 3 in Windows 10 platforms. It happens because git uses SSL and > there’s some bug that causes libssl to crash, killing VM. With the latest vm? Stephan
Re: [Pharo-dev] FW: Versioning with Iceberg
Cyril Ferlicot wrote: > > Configurations were managing project versionning and project > dependencies while baselines are only managing the dependencies since > the project versionning is done by git with it commit by project > opposed to the commit by package of Monticello. Ok, so that makes the handling of projects with lots of packages easier by eliminating the simple problem of having to write down the exact version number of these packages. That helps Stephan
Re: [Pharo-dev] FW: Versioning with Iceberg
Sven Van Caekenberghe wrote: > > >> On 1 Jun 2019, at 10:41, Stephan Eggermont wrote: > >> Could you explain how configurations are simpler? >> >> Stephan > > Because BaselineOfs are simpler than ConfigurationOfs. > > Of course, they don't do the same thing, since tags/branches in git manage > versions. That is not what I see actually happening with baselines. They are referring to branches and versions Stephan
Re: [Pharo-dev] FW: Versioning with Iceberg
ducasse wrote: > Now migrating to iceberg is super easy and configurations are a lot > simpler than with monticello. Could you explain how configurations are simpler? Stephan
Re: [Pharo-dev] Handling of deprecation packages
Torsten Bergmann wrote: > The problem with the new vs. old streams seems to be that migration is > unfinished even for the base image. > Development already switched quickly to newer construction sites instead > of finishing these old ones. There are indeed several open issues with the new streams usage. I posted one on the handling of filing in fileouts by drag and drop. The issue I see with existing code is mostly that an object is used as a stream but is actually an information holder which understands much more than the stream protocol. Rewriting that code to use a streamHolder can be non-trivial. The fallback behavior of a readWriteStream opened on a read-only file is also not easy to get right. Stephan
Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)
teso...@gmail.com wrote: > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. Yes, I want to Stephan
Re: [Pharo-dev] PR2789, Rubric integration revert
ducasse wrote: > Hi stephan > >> Unless someone is working on fixing it today, I want this PR reverted. >> Issues 2865, 2963, 2964, 2980, 3013 >> >> Stephan > > Nobody is working on Pharo this is well known. I am feeling angry and ignored. I am trying to contribute and am frustrated in doing so. I am asked to go through fogbugz and make sure that important issues are reopened on github. I do so and get comments that bugs don’t solve themselves, on the one where I notice that Rubric is not ready. I find and fix important other bugs and try to integrate them and notice that a lot of things don’t work as they should. CI has been systematically red. The first thing I notice is that an in-image test is red, with a trivial to fix issue. Then I run into all kinds of other problems with Rubric not implementing something. And I’m not the only one, looking at the issue tracker. So I look back trough github and see no signs of improvements in the past 14 days. I collected the relevant issues and reached out on github and discord first, without getting a useful reaction. This is not the development process we are using, as I understand it. Please revert the PR. I have been working on FFI, Taskbar and CI bugs and I want to be able to commit, integrate PRs and make Pharo better. Pharo is mine. > > Sorry but I did not like the ton of your email, especially because there are > lot of information that you do not know. I’m up to date with the github commits, issues and PRs, Discord and the mailing lists. If you feel contributors need more information, please make sure we get it > Now if you want to help, add the issue to the projects so that I can work > on them with Alain > and others. Else I will do it. Projects don’t work yet. If you want time to focus on Rubric only and don’t want other contributions to Pharo 8 at the moment, then please announce so. Or use a branch. Don’t integrate a PR that breaks CI and then don’t fix the issues for two weeks. Stephan
[Pharo-dev] PR2789, Rubric integration revert
Unless someone is working on fixing it today, I want this PR reverted. Issues 2865, 2963, 2964, 2980, 3013 Stephan
Re: [Pharo-dev] Missing tests for FFI in CI
Guillermo Polito wrote: >> >> BOOL GetExitCodeProcess( >> HANDLE hProcess, >> LPDWORD lpExitCode >> ); >> > > what are your mappings for BOOL, HANDLE and LPDWORD? Those are user defined > types :) > I downloaded the stable version of OSWindows from the catalog Stephan
Re: [Pharo-dev] Missing tests for FFI in CI
ducasse wrote: > Hello Stefan > > Can you report the exact call you were doing? > I talked with G and Pablo and the bug they fixed is not the same. > Now they would like to experiment and write tests for all the platform. BOOL GetExitCodeProcess( HANDLE hProcess, LPDWORD lpExitCode ); I was trying to get the exit code of a running process on windows. That didn’t work, so we started again with OSWindows on a clean Pharo 8. There we noticed that the currentProcess was not [ 255 255 255 255 255 255 255 255] but [ 255 255 255 255 0 0 0 0]. That (and the test being green in 32 bit) triggered the idea. We did a quick and dirty change to verify, and then found out that the Squeak code had cleaner fixes. Stephan
[Pharo-dev] Missing tests for FFI in CI
Yesterday, we tracked down a serious issue in 64 bit FFI. After giving up with our own code, we made a fresh start with the latest base image and OSWindows. We were finally able to figure out what went wrong with two simple tests that were failing in 64 bit that worked correctly in 32 bit. FFIConstantHandleType externalType is the wrong size After confirming that and making it work, we were told that a number of FFI fixes were done by Nicolas and Eliot in Squeak that did not get integrated in Pharo. Applying the changes from the latest Squeak FFI resolved the problem, and a few that we were unaware of. Stephan
Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:
ducasse wrote: > > I imagine that sven did not add it because on infinite stream it does not > make sense. > Now it would be good to see how we can have useful extensions. But I let this > to sven. That sounds like something that would be useful to make explicit: isInfinite, with blocking, returning nil, returning null objects, or returning errors as possible expected behaviors? Stephan
Re: [Pharo-dev] Migrating XML support to github/PharoContributions/
Albrecht Baur via Pharo-dev wrote: I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) That needs a bugfix, old mczs might not be utf8. You can probably retry with latin1 or macroman. Beware of issues like https://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008990.html You might find WideString there, different encodings, or a dropped leading character, and code where the method contents are changed but the timestamp didn’t and the other way around Stephan
Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:
Sven Van Caekenberghe wrote: > > > "Check the selectors used in the latest packages on squeaksource, ss3, > smalltalkhub and decide." > > are pure technical, intellectual arguments and not passive-aggressive > criticism. Right. Yes, it is a very, very serious response. A few years ago I did some prototypes with DeprecationFinder and MonticelloProjects, applying it to a subsection of smalltalkhub. This is essential infrastructure. Both for deprecations and to recover dependencies. Should be easy to get a paper out of it. Stephan
Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:
Sven Van Caekenberghe wrote: . > > So I propose to remove [Stream|Collection]>>#write: > > What say thou ? Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide. Stephan
[Pharo-dev] Slowdown in writing code (to changes?) in 7 vs 6
Writing code in this way seems to be about 2.4 times slower in Pharo 7 vs Pharo 6. I also tried with smaller numbers, and there I noticed a rather high number of calls to File>>basicOpenForWrite:. With 4*4*4 methods, 768, and 5*5*5 1502. |organizer aToZ| organizer := RPackageOrganizer default. aToZ := 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'. [ aToZ do: [ :ch | |packageName package| packageName := 'Package', ch asString. package := organizer createPackageNamed: packageName. aToZ do: [ :classCh | |cls| cls := Object subclass: (ch asString, 'Class', classCh asString) asSymbol instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' package: packageName. package addClassDefinition: cls. aToZ do: [ :m | cls compile: m asString asLowercase, String cr, ' ^self' ] ] ] ] timeProfile (221 s vs 93) Do I need all those calls to #basicOpenForWrite? Stephan
Re: [Pharo-dev] Better management of encoding of environment variables
Guillermo Polito wrote: > Hi Stephan, > > I'm sorry for the noise. No problem, just trying to understand where we want to go. Stephan
Re: [Pharo-dev] Better management of encoding of environment variables
Nicolas Cellier wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because > the purpose of a VM is to provide an OS independant façade. > I made progress recently in this area, but we should finish the > job/test/consolidate. > If someone bypass the VM and use direct windows API thru FFI, then he takes > the responsibility, but uniformity doesn't hurt. That sounds like a very good idea. Do you suggest to do that after the Pharo 7 release? Or is it simple enough that it can be done in time? On the unix side, do I need the explicit encoding or can I ask the OSEnvironment for the one I need? Before the Pharo 7 release we need at least a #getEnv: back and a class comment corresponding to what is expected. If we want to change to the new API it needs to be deprecated. Stephan
Re: [Pharo-dev] Better management of encoding of environment variables
Guillermo Polito wrote: > Hi all, > > following the meeting we had here @Inria headquarters, I'll be backporting > some of the improvements we did in the launcher this last month regarding > the encoding of environment variables. > > I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ > > We have already studied possible alternatives with Pablo and Christophe and > we have some conclusions and we propose some changes: > > API Proposal for OSEnvironment > = > > >- > *at: aVariableName * > > Gets the String value of an environment variable called `aVariableName` > It is the system reponsibility to manage the encoding. > Rationale: A common denominator for all platforms providing an already > decoded string, because windows does not (compared to *nix systems) provide > a encoded byte representation of the value. Windows has instead its own > wide string representation. > >- *[optionally] rawAt: anEncodedVariableName* > > Gets the Byte value of an environment variable called > `anEncodedVariableName`. > It is the user responsibility to encode and decode argument and return > values in the encoding of this preference. > Rationale: Some systems may want to have the liberty to use different > encodings, or even to put binary data in the variables. > >- *[optionally] at: aVariableName encoding: anEncoding* > > Gets the value of an environment variable called `aVariableName` using > `anEncoding` to encode/decode arguments and return values. > Rationale: *xes could potentially use different encodings for their > environment variables or even use different encodings in different parts of > their file system. > > Other Implementation details > = > >- VM primitives returning paths Strings should be carefuly managed to >decode them, since they are actually C strings (so byte arrays) disguised >as ByteStrings. >- Windows requires calling the right *Wide version of the functions from >C, plus the correct encoding routine. This could be implemented as an FFI >call or by modifying the VM to do it properly instead of calling the Ascii >version > > What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is public API Stephan
Re: [Pharo-dev] Bad baseline practices
Cyril Ferlicot wrote: > On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev > wrote: >> >> >> >> I’m not sure why, but I’ve noticed baselines being changed to refer to >> patch versions for releases. Why are the old configuration problems >> repeated? > > Which project are you talking about? In a plain Pharo 7 image BaselineOfCalypso BaselineOfCommander BaselineOfSystemCommands Stephan
[Pharo-dev] Bad baseline practices
--- Begin Message --- I’m not sure why, but I’ve noticed baselines being changed to refer to patch versions for releases. Why are the old configuration problems repeated? Stephan --- End Message ---
Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"
Christophe Demarey wrote: > Why not following git flow? Because git flow has branches that don’t add value? Stephan
Re: [Pharo-dev] halos
--- Begin Message --- Esteban Lorenzano wrote: > Then you need to be a bit more precise than just saying “it does not works anymore” :) > > Anyway, I can’t reproduce your problem. > > Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 > (64bit) > > And latestVM, still works for me on windows. > PharoLauncher Pharo 7 (development version) list isn’t updated anymore, stuck at 1384. 1411 works for me too. Thanks, Stephan --- End Message ---
Re: [Pharo-dev] halos
Esteban Lorenzano wrote: > They work for me. > Same combination as always (alt+shift+click) Not on 1384-64 in Windows with the latest vm Stephan
[Pharo-dev] halos
What happened with halos in Pharo 7? They don’t show up anymore Stephan
Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore
Chris Muller wrote: >> Earlier, we’ve seen projects like Magma being overwhelmed by the number of >> needed changes, > > I'm curious what you meant by this. I'm not aware of Magma ever > having been overwhelmed. Its design has made it easy to be one of the > most-available and consumable pieces of software for every version of > Squeak from 2007 to today. Did you mean the Pharo port? It doesn't > really do any magic, I'd be surprised if it would be very difficult to > port to Pharo, but I don't know. Several people have been working on a Magma version for Pharo. At the time (Pharo 1.0-1.2) the Pharo CI infrastructure was not giving enough feedback to keep the port running. Once a year or so someone comes along who tries fixing the port, and that appears to be too difficult or time consuming for them. It needs pretty deep knowledge about internals. I agree that it would probably not be very difficult for a long time pharo/squeak developer. Finding out what exactly changed and why in the past 8 years is not so easy for someone new. Without someone using it in production on Pharo, there is not enough incentive to keep up with what changes in Pharo. There’s a chicken and egg problem there Stephan
Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]
Ben Coman wrote: > On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users < > pharo-us...@lists.pharo.org> wrote: > What is the current status of this? DelaySpinScheduler is default in my recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. Stephan
Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore
Tim Mackinnon wrote: > > In retrospect, I’m wondering if successful projects that have proved > integration usefulness should be moved into the core repo? > (Iceberg/Calypso?) or are we missing something to help easily track the > journey of a multi faceted change (although this sounds overkill?). Or > are there sprint days to try and knock these things through easily with > everyone on board to do it together? > > We are sort of damned if you do and damned if you don’t. But certainly we > want to endure that progress can be made without losing the will to > contribute. > Indeed. Putting things in one repo cannot scale and cannot be a solution for something that is neither core pharo nor an application. I encourage everyone who wants to get a good description of this problem to read "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management" by Peter van den Hamer & Kees Lepoeter. With git and github a solution to decouple fast-moving from slow-moving projects seems to be indeed to fork and make PRs. That only works if the quality of the PRs is high enough and we manage to use the feedback from slower-moving projects well. Earlier, we’ve seen projects like Magma being overwhelmed by the number of needed changes, and Pier being broken by Pillar not respecting its constraints. With tools like Travis, it is quickly clear if a PR would result in a green build in the original repo. With projects where Pharo uses only the core, and applications use more than that, the applications still have a dependency problem: if the core changes in Pharo influence the other parts, someone needs to do the work to make those parts work again. With forked repos, that can be a pharo maintainer, the project maintainer or the application maintainer. All three need to be able to make those changes. And they need to be decoupled from having to make them immediately. And being able to have the discussion about the exact implementation independently from implementing a stop-gap solution now is also valuable. So if Calypso is supposed to be extendable and only the core part is part of Pharo, having it as an external project makes sense. With a fork for Pharo to move at its own speed. If Iceberg is Pharo-only, just having different branches for different Pharo versions, it sounds to me like it might be better of in the Pharo project. Tonel is supposed to be cross-platform so should be separate. Is this helpful? Stephan
Re: [Pharo-dev] [Moose-dev] [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation
Tudor Girba wrote: > Hi, > > Bloc is a new world and the intention is to build a new stack on it. It > can be embedded in Morphic, but not the other way around. Higher level > frameworks, like Spec would have to build a renderer for Bloc. Which of course doesn’t stop you from opening a morphic menu on a bloc mouseclick. Here I open a ColorChooser https://vimeo.com/236419682 Stephan
Re: [Pharo-dev] IMPORTANT: ML Etiquette
Tim Mackinnon wrote: > In a world of mobile phones, I think you have to accept top posting, it’s > just too hard to work otherwise on a small screen ... that said, quoting > a small piece to reply to - is doable, and I think we can all try to do that? I strongly prefer ML-etiquette. > Sent from my iPhone That supports NewsTap, which makes it easy to not top-post. I’m not sure why lines are not broken though. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Norbert Hartl wrote: > How can pillar kill pier? They can not both be loaded. Pillar should have just forked: copy and rename the parts needed. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Esteban Lorenzano wrote: . > > Pillar did not kill Pier. > Pier was killed by the fact that nobody is using it (then, there is few > efforts to maintain it). > which is sad, because Pier was/is very powerful… > No. Pillar killed Pier by breaking it unnecessarily. A lot of times. No Pillar maintainer ever looked at our Pier builds and tried fixing things in a compatible way, or committed a fix when they broke something. Pier is stable and works just fine. It is infrastructure and nobody makes money with it, so maintenance is never going to be high priority. If you take up responsibility for changing core, you make sure the higher level still works. If you don’t want that, fork Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Denis Kudriashov wrote: > If two entities needs separate versioning they should be in separate > repositories. Do you agree with this? They don’t, and shouldn’t. That is the way Pillar killed Pier. No separate maintaining of core constantly breaking users. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Tudor Girba wrote: > I do have a strong opinion about baselines: The baseline problem exists > already at a significant scale and is not a local one. they are too > costly to maintain now, and we need to build tools anyway to handle them > cheaply. Without those tools we are confined to manual work, and > optimizing design around manual work is not a good direction. So, trying > to optimize one project is not particularly useful. We can only start from where we are. I’m sure that better tools will help, and pushing for things to be structured in a way that gives us more work now makes it take longer to get those tools. Groups are at the moment essential to minimize manual work. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Denis Kudriashov wrote: > 2018-05-25 20:03 GMT+03:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >>> >>> Because when you will fix or improve Beacon-SysLog you will probably do >> not >>> want to update Beacon-Core version which will force you to update Pharo >>> (where SysLog is not loaded). >> >> I seem to be missing something here. Why would you update the baseline for >> that? >> > > Question is not about baselines. > Separate repositories for Core and loggers are required to version them > separately. > It will allow users to load Core version 1.1, SysLog version 2.0 and > FileLogger 3.0. > And it will allow maintainers improve these projects separately. As I was > described the fix in SysLog will not require updating BeaconCore which is > included in Pharo. You do not have a use case for separate repos, but one for duplicates of the same repo. You need that anyhow because your images depend on different branches and versions. You might want to solve that by having only one image responsible for source code management, and all others connecting to that instead of using libgit directly. Stephan
Re: [Pharo-dev] Crash on GC garbageCollect
Esteban Lorenzano wrote: > > >> On 25 May 2018, at 23:48, Stephan Eggermont wrote: >> >> Esteban Lorenzano >> wrote: >>> that’s because 6.1 images still comes with an old VM. >>> I think I will backport the newer, but next week (testing time has passed, >>> I think). >> >> You probably want to include the TLS fix from this week for Win7 so github >> repos eork > > no I do not want :) > because in that case I will need to repeat the full cycle: 2 weeks as > latest, one month as stable in 7.0, than backport. > and probably in that moment there will be another fix to include. I understand that you don’t want, but releasing a stable vm for Pharo 6 where Iceberg (that is, github) doesn’t work on Win7 is also not really a solution. Stephan
Re: [Pharo-dev] Crash on GC garbageCollect
Esteban Lorenzano wrote: > that’s because 6.1 images still comes with an old VM. > I think I will backport the newer, but next week (testing time has passed, I > think). You probably want to include the TLS fix from this week for Win7 so github repos eork Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Norbert Hartl wrote: > Really?? Don‘t you think the overhead is massive compared to the gain? As long as the baselines are nice trees, described only one level deep, it should be ok-ish. That never seems to be the case though, and as soon as you get diamond dependency issues the duplication of volatile information creates a lot of commit ripple I’d would like to see a description of how that is supposed to work with all the duplicated baselines and repos. Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Denis Kudriashov wrote: > > Because when you will fix or improve Beacon-SysLog you will probably do not > want to update Beacon-Core version which will force you to update Pharo > (where SysLog is not loaded). I seem to be missing something here. Why would you update the baseline for that? Stephan
Re: [Pharo-dev] Beacon for Pharo 7
Denis Kudriashov wrote: > Hi. > > I was looking at Beacon again to prepare integration. Some changes was > needed in baseline for better granularity. So I send pull request because I > have no permissions. > > But now I remember that we had idea to integrate only core part of Beacon > which requires MemoryLogger and TranscriptLogger. And we wanted to manage > logger backends using separate baselines. So we need separate repos to have > separate versioning. Why would you want separate baselines for that? And on top of that separate repos? Stephan
Re: [Pharo-dev] Pharo 7 on SqueakJS (demo)
Pavel Krivanek wrote: > Hi, > > with some tweaks mostly related to FFI and fonts, we are able to run Pharo > 7 on SqueakJS VM. > > Do not expect blazing performance. Currently, it is about two orders of > magnitude slower than the native VM. > > https://pavel-krivanek.github.io/pharo/pharo.html > > Cheers, > -- Pavel > > Cool. It works on my phone. Stephan
Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7
Sean P. DeNigris wrote: > Tim Mackinnon wrote >> Hi what does it mean “Iceberg does not manage yet upgrade of the local >> clones” > > This is most commonly encountered when one enables shared repository > location in Iceberg. And that also breaks when you need to work on different branches, so a shared repository location is at the moment not a recommended setting? Stephan
Re: [Pharo-dev] Esteban's ChangeLog week of 30 April 2018
wrote: > > This should provide backward compatibility on baselines (who can > still be declared with +github://+ etc. protocol) and > makes tonel format available up to Pharo 3.0 versions (since it does > not depends on iceberg presence anymore). That is great! Thanks! Stephan
Re: [Pharo-dev] Fwd: ByteArray>>at:put:
Sven Van Caekenberghe wrote: > > >> On 26 Apr 2018, at 15:21, Sean P. DeNigris >> wrote: >> >> Relevant to Pharo? >> >> From http://forum.world.st/ByteArray-at-put-tp4955848.html : > > We don't (want to) mix binary and character collections or streams. Going > from one to the other is called encoding and decoding, it has to be done > while being conscious of which encoding you are using. Sending > #asByteArray to a String or #asString to a ByteArray is dangerous, lazy > and wrong (in most cases), especially in an international context. How do we capture these kinds of decisions? This is crucial information for people trying to migrate to Pharo. Stephan
Re: [Pharo-dev] Do we kill the catalog?
Thierry Goubier wrote: >No +1 > > Just write that ston now for the current state of OSProcess (with all > versions and platforms supported). > > Or write that ston for a project that has stable branches for all pharo > versions, from say 1.3 to now. > > But, in a way, please do the way you like, and, well, a few years down > the line, we're back at the same situation as now. > > Not that I wish it, but I can see when someone is solving a problem with > yet another way of having the problem. Indeed. Stephan
Re: [Pharo-dev] Do we kill the catalog?
Gabriel Cotelli wrote: > And please support the use of baselines. Nobody wants to also mantain a > ConfigurationOf just for the catalog when using baselines. That sounds like a non-problem. One file that never needs to change. Let’s solve the problems first Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
On 20-03-18 08:55, Stephan Eggermont wrote: Cyril Ferlicot D. wrote: Le 19/03/2018 à 18:49, Stephan Eggermont a écrit : Then why bother releasing? Hi, For people using Pharo 7 to not get the same bugs for more than 1 year, to get the new functionalities and to be able to detect new bugs introduced in releases. Forgive me for sounding like a broken record. How exactly is this style of releasing going to help with these points? Anyone? Because AFAIK this just results in release cascades, and that is definitely bad practice. As soon as a dependency needs to change, you need to make a new release. Stephan
Re: [Pharo-dev] PharoDays: 14/15 June 2018
Stephane Ducasse wrote: > Hi All > > We would like to organise PharoDays the 14 and 15 June. Could you tell us > if you see big problems from your side before we announce it. Works better than 7/8, which I cannot make Stephan Eggermont
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Cyril Ferlicot D. wrote: > Le 19/03/2018 à 18:49, Stephan Eggermont a écrit : >> Then why bother releasing? >> > > Hi, > > For people using Pharo 7 to not get the same bugs for more than 1 year, > to get the new functionalities and to be able to detect new bugs > introduced in releases. Forgive me for sounding like a broken record. How exactly is this style of releasing going to help with these points? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > 2018-03-19 9:16 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >>> 2018-03-17 17:01 GMT+01:00 Stephan Eggermont >> : >>> >>>> Denis Kudriashov >>>> wrote: >>>>> >>>>> No. Each build just loads specified version. I do not need to create >> new >>>>> version for new build. >>>>> But I think I still not understand you >>>> >>>> That specified version will no longer work in a newer pharo build. Pharo >>>> changes, making it necessary for your dependencies to change. Will you >> make >>>> a new release each time one of your dependencies needs to change? >>>> >>> >>> I do not put dependencies of projects which are part of standard Pharo >>> image. So Pharo updates do not affect my baselines >> >> And your dependencies are not impacted by standard pharo changes? >> > > It can be impacted of course. But it is normal process for alpha Pharo 7. > And Pharo 6 is fixed, so I do not care. Then why bother releasing? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >>> >>> No. Each build just loads specified version. I do not need to create new >>> version for new build. >>> But I think I still not understand you >> >> That specified version will no longer work in a newer pharo build. Pharo >> changes, making it necessary for your dependencies to change. Will you make >> a new release each time one of your dependencies needs to change? >> > > I do not put dependencies of projects which are part of standard Pharo > image. So Pharo updates do not affect my baselines And your dependencies are not impacted by standard pharo changes? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > > No. Each build just loads specified version. I do not need to create new > version for new build. > But I think I still not understand you That specified version will no longer work in a newer pharo build. Pharo changes, making it necessary for your dependencies to change. Will you make a new release each time one of your dependencies needs to change? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > 2018-03-17 13:15 GMT+01:00 Stephan Eggermont : > >> Denis Kudriashov >> wrote: >> >>> So to get all minor fixes from all dependencies the code should be loaded >>> from such floating branch (0.5.x). The main project can be locked to fix >>> current version (only dependencies will be updated). >>> And all released versions (0.5.3 tag) will be completely reproducible. >>> >> >> So your goal for released versions is to be only loadable on a specific >> pharo build? >> >> > On any pharo build. I not understand what you mean Your dependencies will need to be updated to run on newer pharo builds, won’t they? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > So to get all minor fixes from all dependencies the code should be loaded > from such floating branch (0.5.x). The main project can be locked to fix > current version (only dependencies will be updated). > And all released versions (0.5.3 tag) will be completely reproducible. > So your goal for released versions is to be only loadable on a specific pharo build? Stephan
Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher
Marcus Denker wrote: >> On 9 Mar 2018, at 23:34, Torsten Bergmann wrote: >> >> Additional portable versions would be nice too (based on a simple ZIP) >> instead of only the installable apps >> > > Is there a deeper reason for this? If I look at “other systems”, they > manage to have *one* download, *one* way of installing. > For me, offering *a lot* of possible different ways means that the user > has to choose without knowing why there is even the option to choose… Yes. I want the live usb stick experience Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Denis Kudriashov wrote: > > It is clear that we need both baselines for that case. > But because we will move Calypso to Pharo repo I think it is easy to manage > strong versions directly in Pharo loading script for now (in #loadCalypso > method). Easy for now, yes. And also a bad example for others to follow. And something that doesn't scale. Where is the increased modularity going to come from if we still manage everything as a monorepo? Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
Guillermo Polito wrote: >... > > So yes, it may block upgrades, but until we have tools that allow us to > cope with the complexity, I prefer to have reproducible versions where I > can reproduce bugs in a reproducible way than an unpredictable version > where I cannot grasp the cause of a problem :/. I strongly advice against using Baselines for that. They are supposed to be edited from hand, and using them for reproducible versions will break other projects, as we've seen earlier with Configurations. AFAIK Metacello can register which versions were loaded in which order, so that information should be recorded for reproducibility. Stephan
Re: [Pharo-dev] Released versions in Pharo Bootstrap
teso...@gmail.com wrote: > Hello, > i have seen in the latest version of Pharo baselines pointing to > "floating" versions. A version that is not fixed. I want to know why this > is like that? Because that is the way it should be? It is hand-edited, so repeatable builds are not the goal, just working software. Repeatable builds come from recording what you loaded in what order. Repeatable builds with fixed dependency versions don't help you with working software, as they block your dependencies from getting patched. Never depend on hard-coded versions of anything you don't control yourself. See the 5D paper Stephan Eggermont
Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:
Sean P. DeNigris wrote: > Or are you saying there should be a collection of rewrite rules even after > the method is totally removed so one can bring a very old project up to the > newest APIs? Making sure the code works in each intermediate version of Pharo is increasingly unattractive. It also requires indefinite support of all the old pharo versions. A collection of separate rewrite rules looks to me like the right thing to both explain changes and speed up migrations. Stephan
Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:
Sven Van Caekenberghe wrote: > Either we keep on adding cruft (or leaving cruft in place) in the sake of > backwards compatibility or be do something about it. It is not hard to > fix a couple of senders. It could be done more softly with a deprecation. > > Cleanups at the level of Object are particularly valuable. It needs to be done in a way that is sustainable. That means with a code rewrite rule. Deprecations are not enough. The number of people who can migrate forwards older code is very small, especially as we are missing crucial parts of design discussion that took place on slack and were not copied to mail. When I created my Morphic screencasts I had to look back to mailing list discussions from 10 years ago and had to run ancient squeak images to gain an understanding of how things were supposed to work and how they changed. Cleanups at this low level need to be done with rewrite rules (and tests) Stephan
Re: [Pharo-dev] Problem to save packages
Nicolas Cellier wrote: > These are my files, I want to be in control and manage them by myself. > Eventually save them on another medium, and not mix them with thousands of > other files that generally populate a package-cache. > Do you see what I mean? Two aspects: 1 It sounds like you have a shared package cache for all your images? That is somewhat incompatible with the current tooling, especially with regard to reproducible loading of Metacello configurations. Having lots of duplicated mcz's in each image's package cache is wasteful 2 Yes, having much more control over the package cache makes sense, especially with TelePharo. Different scenario's need different strategies. Mixing new, own code with loaded frameworks is not very practical Stephan
Re: [Pharo-dev] Problem to save packages
Nicolas Cellier wrote: > But whatever the bug, why saving in the package-cache? > The package-cache is just a cache as the name tells. > It's less volatile than RAM, but can still be subject to aggressive cleanup. Because it is much more reliable than network, and it depends on simpler and working infrastructure. The package cache is deliberately not cleaned, and not shared by default. Stephan
Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year
Esteban Lorenzano wrote: > Hi all, > > After some analysis of current condition of development, we decided to > move the upcoming release to end of the year (and not May, as usual). Thanks for the clear and timely decision. Having to delay is never nice, but with a high innovation rate comes a higher risk. Denial helps noone, keep up the good work! Stephan
Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!
Luke Gorrie wrote: > For me it's another story. I'm on an unsupported platform (NixOS Linux), > I'm building the VM from random git commits because the source releases are > all antiquated, Iceberg segfaults the moment I start it, and > epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of > obstacles between me and maintaining my application. Isn't nix supported by travis? I suppose that means that you should be able to automatically build a variant of opensmalltalk I have absolutely no idea how much work that would be though. Stephan
Re: [Pharo-dev] Blame support P7
Sven Van Caekenberghe wrote: > (1) what non-trivial code is actively maintained from a single code base > between Pharo, Squeak and Cuis ? That is nice, but too limited a question What about the need to maintain non-trivial large code bases between multiple smalltalks? If we only limit ourselves to open source, just look at Glorp and PDFTalk. Stephan
Re: [Pharo-dev] Blame support P7
Eliot Miranda wrote: > Hi Stephan, > Then why on /earth/ would one stop using Smalltalk in /the most central > part/ of the collaborative programming process, version control? Because of the underestimation of the work needed, vs. the advantage of eliminating one barrier to entry. One of the differences in perspective is that Stef sees lots of people new to smalltalk (students) and needs them to get up to speed really fast. The collaboration needs there are different from yours, where you need to deal with long-term collaboration mostly between experts. There is also a significant underestimation of the complexity of version control, and the need to support different workflows. The community members having experience managing complex workflows don't manage to explain well enough what they need. Stephan
Re: [Pharo-dev] Blame support P7
Eliot Miranda wrote: > Isn't it important to preserve the ability to exchange code between Pharo, > Squeak and Cuis? Don't you care that the VM development is directly > affected by this? Is the VM and plugin support not important to Pharo? Git support turns out to be much more work than we hoped and expected. Too many library updates needed, support for different workflows and platforms, switch to file per class. The Iceberg channel on Discord is one of the busiest channels. Stephan
Re: [Pharo-dev] New Year Wishlist (2018) ?
Esteban Lorenzano wrote: > Hi everybody, > > This looks like a good moment of the year to ask all of you what would > you want to see in Pharo next year. I wish you all the time and good health to realize some of your Pharo dreams Stephan
Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?
Denis Kudriashov wrote: > Hi Bernhard. > > The deprecation is still in progress. Considering the amount of non-image code using this, I would be interested to hear how this is going to be supported and documented. Stephan
Re: [Pharo-dev] [Website] Updated Linux download instructions
On 13-12-17 16:32, Sean P. DeNigris wrote: Marcus Denker-4 wrote I have updated the download instruction… Thanks!! This seems to have been a common pain point, for new users especially. And then a newer 32 bit Linux VM needs to be build and promoted to stable as next point? Stephan
Re: [Pharo-dev] Moving from mc to tonel?
On 05-12-17 08:59, Peter Uhnák wrote: > In my case, it turned out to be a non-UTF8 encoded character in one of the commit messages. I've ran into this problem in a sister project (tonel-migration), and do not have a proper resolution yet. I was forcing everything to be unicode, so I need a better way to read and write encoded strings. :< To be exact, exactly none of the older commits will be UTF8 encoded. For most it doesn't matter as they are ASCII, but if we want to have a change of converting older french or german code (or japanese), we need support for what was done with WideString. That probably needs a look in the squeak mailing list archives. Stephan
Re: [Pharo-dev] create snapshots out of github based packages
Op 10-12-2017 om 15:44 schreef Cyril Ferlicot: On dim. 10 déc. 2017 at 15:07, Nicolai Hess And I don't mean 1 or 2 thousand files. Loading bloc for example creates over 20.000 files. This is damn slow on windows. This is one of the reasons Esteban created Tonel I think. With Tonel there is 1 file par class instead of 1 file per method. Once it will be really stable, moving projects to Tonel should speed up things on Windows. Indeed. An even larger problem is the write amplification: Minimium disk file size of 4KB means a slow down of a factor 20. 1 (primary) file per class and sorting the methods helps a lot. Doing that in a cross-platform compatible way so we can easier share source code needs some further refinement Stephan
Re: [Pharo-dev] Where is the latest linux vm?
On 02-12-17 11:18, Thierry Goubier wrote: Le 02/12/2017 à 11:00, stephan a écrit : On 01-12-17 21:21, Thierry Goubier wrote: To avoid segfaults, I'm using one from November. Where does that come from? Or do you compile it yourself? It comes from the bintray opensmalltalk folder. For example, https://bintray.com/opensmalltalk/vm/cog/201711061254#files I've never had much success compiling it myself. Ha. I found the latest in https://bintray.com/opensmalltalk/vm/cog/201712010755#files But there is no 32 bit linux x86 pharo build there, only the 64 bit. Stephan
Re: [Pharo-dev] Where is the latest linux vm?
On 01-12-17 21:21, Thierry Goubier wrote: To avoid segfaults, I'm using one from November. Where does that come from? Or do you compile it yourself? Stephan
Re: [Pharo-dev] Where is the latest linux vm?
On 01-12-17 18:56, Alistair Grant wrote: On 01-12-17 11:16, stephan wrote: Is the latest really from august? I have: Date: Sun Aug 27 21:55:26 2017 +0200 So what happened in the past two months? Stephan
Re: [Pharo-dev] Where is the latest linux vm?
On 01-12-17 11:16, stephan wrote: Is the latest really from august? Ping
[Pharo-dev] Where is the latest linux vm?
Is the latest really from august? Stephan
Re: [Pharo-dev] Iceberg workflow
On 28-11-17 22:08, Torsten Bergmann wrote: Having the code directly in the root is possible but not a good style or to be recommended - because often projects include more than just the source code and over time include more and more things like docu or other. Thanks for the explanation for where this comes from. This helps me understand where my confusion comes from: the assumption that there would be one root for source. That is not always the case. There can be multiple sub projects (casually used, not in the git subproject terms), each with their own source root. Mapping from smalltalk code to file systems has all kinds of annoying/interesting aspects. And I understand the difficulty/impossibility/undesirability of supporting everything that git makes possible. I seem to have missed some design discussions/decisions and really like the mails here about them. And I like the booklets very much too. Stephan
Re: [Pharo-dev] Iceberg workflow
On 28-11-17 19:40, Torsten Bergmann wrote: 2c) Code subdirectory: enter "src" here !!! Do we really need that? Why would I care about that? Stephan
Re: [Pharo-dev] clarifying pharo crashing issue(s)
On 27-11-17 12:08, Tudor Girba wrote: How do they crash? When you run something specific? Different things. The script crashed reliably on all my machines the last time I checked. Stephan
Re: [Pharo-dev] clarifying pharo crashing issue(s)
On 27-11-17 09:20, Tudor Girba wrote: Hi, There are recurrent reports that Pharo is crashing often. So, first question: - is Pharo crashing on another system than MacOS Sierra or HighSierra? Yes, older MacOS, Ubuntu 16.04LTS, Windows 7 & 10. Both 64 and 32 bit, latest and stable vms. I'm mostly using PharoLauncher One of them is |project| Gofer it smalltalkhubUser: 'StephanEggermont' project: 'MonticelloProjects'; package: 'MonticelloProjects'; load. project := (Smalltalk at: #MCProject) new location: 'http://smalltalkhub.com/mc/StephanEggermont/Documentation/main'. project read. project saveToFile. Stephan
Re: [Pharo-dev] Iceberg operations overview
On 22-11-17 09:33, Pavel Krivanek wrote: during brainstorming of the Iceberg UI simplification we created a document that shows what the current Iceberg operations do. It should help you to clarify the role of the working copy etc. Thanks, that is helpful. From the discussions on discord and here I get the impression that we're not at all aligned on what is actually expected, needed and provided. Without the scenarios that need to be supported, there is no way to decide on how to simplify the UI. From the discussions I get that some integration with Metacello (and/or Cargo) will be needed too. I would like to avoid the problems we earlier had with Komitter. Can we discuss the scenario's (through personas) here first? Cheers, Stephan
Re: [Pharo-dev] [ANN] Willow 4.0.0 released!
Op 16-11-2017 om 15:44 schreef Gabriel Cotelli: Hi, We're happy to announce the general availability of Willow and it's related projects in the Web Stack ecosystem hosted at https://github.com/ba-st/. Willow is a Web Interaction Library that eases the burden of creating AJAX-based web applications. The project goals are: Interesting approach. Might be useful to use as a target for (QC)Magritte. So much things to try out, and not enough time! Stephan
Re: [Pharo-dev] Stuck trying to contribute
Is all this summarized on Guille's (and Thorstens) pages? Stephan
Re: [Pharo-dev] feenk log
On 10-11-17 22:36, Aliaksei Syrel wrote: To wrap up, we decided that it should be a responsibility of the Space _class_ to create a new temporary instance of itself, add an element to it, simulate click event and then delete itself. In order to show the intent and a process behind we decided that it would be a good idea to actually write a code like this: BlSpace simulateClickOn: element. The adding of BlElements to the space, and setting up their responsibilities (to e.g. registering to send announcements to domain model objects, and receive them) is normally the responsibility of an object outside the space, I assume. Also, the creation of temporary instances of itself raises the question of exactly what to copy. Please elaborate a bit on the consequences of this for application and test design. Cheers, Stephan
Re: [Pharo-dev] Is fileout on the change sorter working in Pharo 70?
On 08-11-17 22:03, Stephane Ducasse wrote: File @ /Users/ducasse/Documents/Pharo/vms/70-x86/Pharo.app/Contents/MacOS Yes, this is looks like one of the problems I have with PharoLauncher directories. It is unclear to me what is kept with the vm and what with the image. I asked about it in users Stephan
Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?
On 07-11-17 22:34, Pavel Krivanek wrote: I successfully loaded Seaside into minimal Pharo 7 image: http://forum.world.st/Seaside-on-minimal-Pharo-7-0-td4979763.html Well, loading code that adds methods to the still existing traits works. But if those traits are no longer used, that might result in silent failure. That actually needs a quality rule (or rewrite to also flatten) Stephan
Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?
On 07-11-17 21:25, Esteban Lorenzano wrote: On 7 Nov 2017, at 17:22, Sven Van Caekenberghe wrote: Yes, that is a though one for external libraries. why? (not putting it in doubt, just wanting to know ;) ) Ah, well, it just means that we'll want to replace some code written for pharo 3 or 4 and add it there. Just unplanned work to keep up with Pharo changes. And would have been better handled as a rewrite rule, I think. Stephan
Re: [Pharo-dev] How should I load Seaside/Bootstrap in Pharo 7 ?
On 07-11-17 21:11, Sven Van Caekenberghe wrote: Nobody (trying to use|using) Seaside on Pharo 7 ?? I already did one pull request. That is not enough because of the flattening of traits Stephan
Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:
On 05-11-17 22:05, Stephane Ducasse wrote: I was working in cleaning the users of asLayoutFrame and when I commit I see - #category : 'Morphic-Base-Layouts' + #category : #Morphic-Base-Layouts but #category : #Morphic-Base-Layouts is not a valid symbol. In Metacello we use the quoted symbol form exactly because different smalltalks have different ideas of what a valid symbol is. Stephan
Re: [Pharo-dev] How to update currently used VM for PharoLauncher?
On 04-11-17 20:29, Christophe Demarey wrote: It makes sense only for the development image but it could be a nice option to add to the launcher. Do you think it will be used? I have a personal need for it, but that should of course not be the determining factor. I see several scenario's for this: - A 'normal' user notices a problem, that gets fixed in a development vm. She needs to test and use it, is probably not interested in following all other new development vms, and ideally should switch as soon as possible to using a newer stable vm again. Supporting the automatic switch to a newer stable vm makes sense for us to avoid having too many new users using the unstable versions. It might be useful to make that decision for an individual image, when other projects are not affected by the issue. So here there would be two choices: I want to download a latest (or version) vm and automatically upgrade to a newer stable when that arrives, and I want to use that for only this image or for all fitting images. - At the moment I'm running into a lot of the current vm issues. I have some production images that should be using stable, but in my development I want to just use the latest vm that managed to get green tests :) Nearly all new versions are improvements, but once in a while there are changes that need to be reverted. So there I just want to check before starting an image if there is a new vm I can use, and will just ignore that once in a while there is a broken one. Stephan
[Pharo-dev] How to update currently used VM for PharoLauncher?
I've noticed a few VM updates I want to use with PharoLauncher. What is the currently recommended way to update my PharoLauncher to use a non-stable version? Stephan
Re: [Pharo-dev] Layout for placing widgets
On 28-10-17 16:26, Stephane Ducasse wrote: I was reading ... I will see if I can load cassowary in Pharo. I could get the squeaksource cassowary for morphic working without a problem, just needed some extensions and fixes for changes we made in Pharo. Stephan
Re: [Pharo-dev] Layout for placing widgets
On 28-10-17 23:20, Thierry Goubier wrote: Hi Pavel, Le 28/10/2017 à 22:29, Pavel Krivanek a écrit : Hi Thierry, your repository mentions the MIT license but the original license of the Cassowary package was LGPL. Is is a different code? I ported the original, public domain smalltalk implementation of Cassowary. I also looked at the morphic port on squeaksource which is just a very thin layer of using the public domain code on top of morphic. The author of that was open to have his work relicensed (Apache style, but I never followed up on that) https://github.com/pharo-graphics/Bloc/issues/25 Just applying and adapting Thierry's code should provide us what we need Stephan