2018-04-09 15:28 GMT+02:00 Ben Coman <b...@openinworld.com>: > > > On 9 April 2018 at 14:50, Thierry Goubier <thierry.goub...@gmail.com> wrote: >> >> 2018-04-09 2:18 GMT+02:00 Esteban A. Maringolo <emaring...@gmail.com>: >> > Even if he is a troll, he pointed out many things that aren't given >> > priority because we're building "next great stuff" and with the limited >> > resource you either stop to world to fix what's already made or you move >> > forward. >> > >> > And IMO it is true that the next great stuff is being built, a better >> > paradigm, moldability, and whatnot, but that means that, for a while, >> > tools, and the image itself won't be "rock solid", and since most things >> > are not backportable or maintained (there are no resources to have LTS >> > versions), it is hard to define what's the minimum rock-solid core on >> > which to build upon. >> >> I wonder if some things could be solved by taking a slightly different >> path... >> >> - Non rock solid base could be cared for by debugging that allways work >> >> - Not threaded image could be solved by "image sharing between processes" > > > Can you expand on this. I can't follow.
Have objects freely moving between images (or being duplicated between images). Nothing really outlandish, just your standard either distributed object stuff, or software distributed shared memory (image segments could be the right abstraction). A use case: main image with full tools (one window), linked image with application-only code (one window), each time you compile a method in the main image, linked image gets it because it track system announcer changes. >> - Multiple host windows would mean forking the image > > > I presume your mean native fork(), rather than Smalltalk #fork. Exactly. Thierry > cheers -ben > >> >> >> Imagine a world where: >> - The smalltalk debugger can remote debug via gdb(*) a locked image >> (or one where you have crashed the world because you played with core >> graphics stuff)... >> - The smalltalk debugger can inject new code into a remote image via >> gdb again (**). >> - Two images can easily share objects with almost zero overhead(***) >> - One image can easily keeps its code in sync with another one (object >> duplication between images) >> >> I know of TelePharo, and, after looking at the underlying >> implementation, it's not good enough. The core undebuggability of the >> platform is not solved (at all). >> >> The undebuggability of the platform is a significant barrier. I worked >> on the SmaCC GT debugger because my students were regularly locking >> their images with it (usually something as simple as stepping over the >> end of the computation) so I've added many, many guards, to try to >> protect from that; I know think a strong limitation of exploring new >> debug modes is mainly linked to the ease of locking your image with >> it. >> >> Regards, >> >> Thierry >> >> (*) gdb over serial talking to a boot eeprom equivalent, mapped with a >> remapping of step to smalltalk instructions (like in a true debugger) >> (**) So that, from that smalltalk over gdb debugger, you can fix, >> compile and proceed >> (***) And so, no story of running a "determine the right object graph >> with more smalltalk code... ", that is too slow >> >> > E.g. The infinite walkback error pointed in this screenshot >> > https://i.imgur.com/7jiKIhd.png still chases me from time to time, and I >> > remember having reported it a long time ago, and it was considered >> > fixed. >> > >> > So I wouldn't feed the troll, but I woudln't kill the messenger either. >> > >> > Regards, >> > >> > >> > On 07/04/2018 14:26, Dimitris Chloupis wrote: >> >> yeah the guy (martin whatever) is a troll, if I remember correctly its >> >> the same dude we had on the reddit forum for Smalltalk that has been >> >> attacking Pharo with pure lies. He is a typical troll that blows off >> >> steam by annoying other people. I am with Stef with this one, the only >> >> way to win against a troll is silence. I had a very recent experience >> >> where the person in charge underestimated a troll, he overflown the >> >> mailing list with negative, many people took the bait and tried to have >> >> a civilized discussions with him, he drag it one for month until people >> >> started abandoning the community and the community essentially died. >> >> >> >> I adviced them not to feed the troll but as in many other cases, people >> >> dont even listen. >> >> >> >> Pharo is far from perfect, but this is not a logical discussion , its >> >> pure troll tactic. Do not underestimate the power of a troll, it is >> >> more >> >> powerful than you can imagine and feed on politeness and rationality. >> >> >> >> Don't feed the troll. >> >> >> >> On Sat, Apr 7, 2018 at 8:13 PM p...@highoctane.be >> >> <mailto:p...@highoctane.be> <p...@highoctane.be >> >> <mailto:p...@highoctane.be>> wrote: >> >> >> >> interruptible.. yes! >> >> >> >> On Sat, Apr 7, 2018, 19:10 Thierry Goubier >> >> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>> >> >> wrote: >> >> >> >> Hi Alex, >> >> >> >> Le 07/04/2018 à 17:48, Aliaksei Syrel a écrit : >> >> > Hi >> >> > >> >> > Here is a link to a report about their experience with Pharo: >> >> > https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc >> >> > >> >> > There definitely exist things that should be improved. It is >> >> a >> >> pity when >> >> > tiny “minor” issues leave such an unpleasant aftertaste. >> >> >> >> Some of them are, sadly, quite unacceptable, IMHO. >> >> >> >> I would really dream of a stable, correctly interruptible (i.e. >> >> a Cmd-. >> >> that really works), limited Pharo core. That would help >> >> development so >> >> significantly and allow more experiments. >> >> >> >> I solve that by making stuff that distance itself as much as >> >> possible >> >> from a lot of the Pharo stuff that evolves far too much, far >> >> too >> >> fast to >> >> be relied upon (widgets, graphics, editors), and I'm looking >> >> forward to >> >> building a limited(*) image with just and only the things I >> >> rely on. >> >> >> >> One of the thing I need is a CI that triggers both on my code >> >> releases >> >> and any Pharo update (including the stable ones) since even >> >> stable >> >> releases may change core APIs. >> >> >> >> > Anyway, there are lovers and haters of every language. >> >> >> >> That I can agree with :) >> >> >> >> > Some people even >> >> > give dislikes to videos on YouTube that show how >> >> veterinarians >> >> heal cats... >> >> > >> >> > All the best >> >> > Alex >> >> >> >> Regards, >> >> >> >> Thierry >> >> >> >> (*) I did try with the minimal image, and the tools are clearly >> >> limiting. >> >> >> >> > On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse >> >> <stepharo.s...@gmail.com <mailto:stepharo.s...@gmail.com> >> >> > <mailto:stepharo.s...@gmail.com >> >> <mailto:stepharo.s...@gmail.com>>> wrote: >> >> > >> >> > I tend to not care about people pissing on me via a >> >> pseudo. This is >> >> > too easy and too microscopic to have any value. >> >> > Thanks Philippe, Luke and Ben because you use your real >> >> names. >> >> > >> >> > On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano >> >> > <esteba...@gmail.com <mailto:esteba...@gmail.com> >> >> <mailto:esteba...@gmail.com <mailto:esteba...@gmail.com>>> >> >> wrote: >> >> > > Hi, >> >> > > >> >> > > yesterday someone posted an article on HN about the >> >> Pharo MOOC >> >> > and there has >> >> > > been some negative posts there. >> >> > > I would like to call people who can have the time to >> >> answer there >> >> > and help >> >> > > to explain better and also contribute to contest that >> >> FUD >> >> > someones (we know >> >> > > who they are… sames as always) are spreading. >> >> > > >> >> > > here the link : >> >> https://news.ycombinator.com/item?id=16754872 >> >> > > >> >> > > (this is not loosing time, people searching for Pharo >> >> will likely >> >> > see this >> >> > > kind of messages… at least we need to offer our point >> >> of view) >> >> > > >> >> > > cheers! >> >> > > Esteban >> >> > >> >> > -- >> >> > Cheers, >> >> > Alex >> >> >> >> >> > >> > -- >> > Esteban A. Maringolo >> > >> >
