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

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

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

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

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?

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

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

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

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

[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 );

[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.

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,

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:

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

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

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

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

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 >

[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

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

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

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

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

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

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

Re: [Pharo-dev] Beacon for Pharo 7

Denis Kudriashov <dionisi...@gmail.com> wrote: > 2018-05-25 20:03 GMT+03:00 Stephan Eggermont <step...@stack.nl>: > >> Denis Kudriashov <dionisi...@gmail.com> >> wrote: >>> >>> Because when you will fix or improve Beacon-SysLog you will pro

Re: [Pharo-dev] Crash on GC garbageCollect

Esteban Lorenzano <esteba...@gmail.com> wrote: > > >> On 25 May 2018, at 23:48, Stephan Eggermont <step...@stack.nl> wrote: >> >> Esteban Lorenzano <esteba...@gmail.com> >> wrote: >>> that’s because 6.1 images still comes with an old

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

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

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

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. > >

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

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!

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.

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

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] PharoDays: 14/15 June 2018

Stephane Ducasse <stepharo.s...@gmail.com> 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. <cyril.ferli...@gmail.com> 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 functionaliti

Re: [Pharo-dev] Released versions in Pharo Bootstrap

Denis Kudriashov <dionisi...@gmail.com> wrote: > 2018-03-19 9:16 GMT+01:00 Stephan Eggermont <step...@stack.nl>: > >> Denis Kudriashov <dionisi...@gmail.com> >> wrote: >>> 2018-03-17 17:01 GMT+01:00 Stephan Eggermont >> <step...@stack

Re: [Pharo-dev] Released versions in Pharo Bootstrap

Denis Kudriashov <dionisi...@gmail.com> wrote: > 2018-03-17 17:01 GMT+01:00 Stephan Eggermont <step...@stack.nl>: > >> Denis Kudriashov <dionisi...@gmail.com> >> wrote: >>> >>> No. Each build just loads specified version. I do not need to c

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

Re: [Pharo-dev] Released versions in Pharo Bootstrap

Denis Kudriashov <dionisi...@gmail.com> wrote: > 2018-03-17 13:15 GMT+01:00 Stephan Eggermont <step...@stack.nl>: > >> Denis Kudriashov <dionisi...@gmail.com> >> wrote: >> >>> So to get all minor fixes from all dependencies the code sh

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

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

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

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

Re: [Pharo-dev] Released versions in Pharo Bootstrap

d-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

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

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

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,

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

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 >

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

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

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

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] 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

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

Re: [Pharo-dev] Stuck trying to contribute

Is all this summarized on Guille's (and Thorstens) pages? Stephan

Re: [Pharo-dev] Iceberg Default Subdirectory Setting?

On 20/09/17 23:50, Sean P. DeNigris wrote: I always put my packages in gitroot/repository per instructions I read when I was starting with FT (Dale's IIRC). It's a (minor) drag to type that every time I add a local git repo. How would y'all feel about a setting? Is that shared with multiple

Re: [Pharo-dev] Iceberg

On 19/09/17 17:52, Marcus Denker wrote: I personally find it very confusing that http://files.pharo.org/vm/ does not have the current VMs… Now I am confused. The date seems to suggest they are current? At least on Linux Stephan

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

Frank wrote: > I feel sorry for you if you really have not yet understood that proper, early > and complete documentation and comments ARE ONLY an investment in the code, > because they save time and efforts later on, which always pay back - mostly > multiple times. Perhaps you might want to

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

Hi Frank, It must be very frustrating to see so many possibly interesting projects that are so difficult to get started with, being it because of lack of development and migration to the latest versions, or because of lack of documentation. It is a feeling I, and no doubt a lot of other

Re: [Pharo-dev] Impediment to contributing

On 10/08/17 17:16, Guillermo Polito wrote: I've made some write up for the pharo part (not metacello or external projects) https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo Of course, expect bugs on it :) Not everything is smooth. If you have comments, they are

Re: [Pharo-dev] About cr and lf

On 06/08/17 15:25, Peter Uhnak wrote: Hi, that's why one of the proposals was to configure the stream to either use always specific line endings stream beForWindows. stream newLine. "outputs CRLF irrespective of where the image is currently running" and stream beForCurrentPlatform. stream

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

On 27/06/17 14:56, Sven Van Caekenberghe wrote: P3 is a modern, lean and mean PostgreSQL client for Pharo. Nice! Thank you Stephan

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

On 23/06/17 17:59, Luke Gorrie wrote: Hi again Ben, I have an idea for a hacky way to import all of the Pharo packages into my universe. Shooting holes in this idea would be welcome :). ... Sane? Workable? Fatal flaws? You might want to look at StephanEggermont/DeprecationFinder on sth

Re: [Pharo-dev] please test download for Pharo 6.0

On 02/06/17 23:10, Nicolas Cellier wrote: This is now fixed, you just have to wait for appveyor to finish its job. Guys, I have pushed Win64 VM including the Pharo flavour. Thanks, I appreciate it. It works well in Squeak but I'm not a Pharo user (or very casual). All I'm asking for weeks or

Re: [Pharo-dev] [ANN] Pharo 6.0 released!

On 06/06/17 17:11, Esteban Lorenzano wrote: Dear World, The time has come for Pharo 6.0! Yes! Well done! Stephan

Re: [Pharo-dev] FTs now support single and multi-cells selection

Nice. That looks like we are getting ready to add inline editable table-based views to our browsers. That should work well with Cucumber style tests with examples. Stephan

[Pharo-dev] FileTree/Iceberg and SSDs, change the file format

At the PharoDays I was painfully reminded that SSDs perform really badly when using small files. The Bloc tutorial used a github filetree repo and that has a lot of files. The whole folder is 116 MB in 16K files. Copying that amount of data should not be noticable, taking about a third of a

Re: [Pharo-dev] Anyone meeting up night before Pharo Days (17th?)

On 06/05/17 12:58, Tim Mackinnon wrote: Hi guys - I managed to get a “weeknight pass” so that I can come to Pharo days and try and catch up with all the progress you have made. I’m taking a Eurostar on Wed night (17th) and wondering if anyone is meeting up the night before on the 17th? I don’t

Re: [Pharo-dev] Smalltalk Internet Browser

On 29/04/17 04:11, askoh wrote: Being connected to the internet is going to be a necessity for any piece of software in the immediate future. So every Smalltalk development environment or application should have that capability as default. To push that envelop, every image should have a

Re: [Pharo-dev] changing default theme to DarkTheme

On 21/04/17 15:22, Dimitris Chloupis wrote: its ironic you say this Stephan and the irony is that you claim that Dark Theme is inappropriate because Pharo uses so many hard coded colours when it was Esteban's effort to have a dark theme that decreased the amount of hard coded methods and

Re: [Pharo-dev] changing default theme to DarkTheme

On 21/04/17 13:26, Dimitris Chloupis wrote: On Fri, Apr 21, 2017 at 1:53 PM Ben Coman > wrote: On Fri, Apr 21, 2017 at 4:10 PM, Dimitris Chloupis > wrote: > You know what

Re: [Pharo-dev] changing default theme to DarkTheme

On 16/04/17 23:27, Cyril Ferlicot D. wrote: On 16/04/2017 23:13, Stephan Eggermont wrote: We do not break things a week before the release. We break them a week after the release. Otherwise, why bother. Stephan As I asked in my previous mail, what is broken? There are 214 instances

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

On 16/04/17 16:14, Dimitris Chloupis wrote: Just for the record the easiest way to load packages in the image the Package Browser relies solely on configurations . Is there a plan to migrate because as much I am vocal supporter of Pharo moving to git it will be a big lose if Package Browser is

Re: [Pharo-dev] changing default theme to DarkTheme

On 16/04/17 20:53, Cyril Ferlicot D. wrote: Also, I use the dark theme since almost two years and I don't remember having problems. Do you have examples? Within two minutes I found a non-themed visualization in Moose. The switching works a lot better than last time I looked at dark theme.

Re: [Pharo-dev] changing default theme to DarkTheme

On 16/04/17 20:53, Cyril Ferlicot D. wrote: And last, when a new version of a programming language is out, we do not expect all applications to be up to date with the language at the time of the release. We do not break things a week before the release. We break them a week after the release.

Re: [Pharo-dev] changing default theme to DarkTheme

On 15/04/17 16:02, Norbert Hartl wrote: And comparing the capability of building contrasts with colors, dark colors win, sorry. At least that were the last researches I've read. Which ones? https://webstandards.hhs.gov/guidelines/106 seems pretty clear. Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

On 15/04/17 14:43, p...@highoctane.be wrote: Make it default so that it will bother people enough to fix the glitches. That is fine to do for half a year starting with Pharo 7. I'm all in favor of making changes in development that help us improve. It is definitely not a good idea to make sure

Re: [Pharo-dev] changing default theme to DarkTheme

On 15/04/17 13:48, Sven Van Caekenberghe wrote: It is a matter of taste, of course, but after 5 major releases with White Themes, an alternative is more than welcome. Mostly because it is not a matter of taste. For most people (there are several eye problems where it is not the case), a dark

Re: [Pharo-dev] changing default theme to DarkTheme

On 15/04/17 10:19, Dimitris Chloupis wrote: I am a huge supporter of Dark Themes, they are friendlier to the health of the eye and much friendlier to the environment too. Their objective value cannot be questioned. But as always personal taste plays a role here. All science shows otherwise.

Re: [Pharo-dev] changing default theme to DarkTheme

On 14/04/17 09:09, Esteban Lorenzano wrote: I wanted to let you know that we talked at the board and we want to make the DarkTheme a default for Pharo 6.0. This is just because we want to have a visual immediate reference of changing things (yeah, marketing ;) ) No. Please revert that

  1   2   3   4   5   6   7   8   >