August 2017 - Pharo-dev - lists.pharo.org

Ugly smell: really long symbols/selectors

by Guillermo Polito

#'thisIsAVeryLongSelectorAndIfYoureHereWeHaveOnly49ImagineIHaveToWriteAllThisToArriveTo87ThenThisTo100' (ByteSymbol allInstances select: [ :e | e size > 100 ]) size => 36 (ByteSymbol allInstances select: [ :e | e size between: 50 and: 100 ]) size => 653 -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 16, 2017

File & Socket Handle Access

by Eliot Miranda

Hi All, recently Denis Kudriashov wanted to access the OS handle of a Socket from the image to pass through the FFI. David Lewis pointed out that the AioPlugin provides a primitive to do this. I asked David why he didn't add it to the SocketPlugin in the first place and he discussed Andreas Rabb's security concerns. It strikes me a) that accessing the OS handle of a file or a socket is extremely useful in some circumstances and invalid in others b) having handle access in a secondary plugin is inconvenient to say the least c) having access only to Socket handles and not to file handles is also inconvenient. So I propose adding a SecurityPlugin facility to control handle access, which would be granted by default, and to add primitives to both the SocketPlugin and FilePlugin to answer the native OS handle when the SecurityPlugin grants permission. I also propose adding a compilation flag to the Windows VM to allow compiling out Andreas' handle management, which consists merely of maintaining a table of the file handles (not the socket handles) that have been created by the VM. It strikes me that a much better solution is merely to encrypt the handle via xoring with a value created at random. I don't see how Andreas' solution adds value, especially since it is not implemented on other platforms, and merely adds overhead. Thoughts? Objections? _,,,^..^,,,_ best, Eliot

Aug. 16, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Guillermo Polito

On Tue, Aug 15, 2017 at 3:25 PM, Ben Coman <btc(a)openinworld.com> wrote: > In case any of the shutdown/startup scripts use a delay, now or in the > future, > I'd first try at highestPriority-1 to avoid influence on the > DelayScheduler. > but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. > Why should a shutdown/startup use a delay? startup and shutdown should be fast and not be blocked... If there is a delay on client code, it should block a client thread, not a system thread... Moreover, I see a series of issues in having the delay process running in higher priority than the startup. If I'm wrong, please correct me because otherwise that means there is something I'm not getting. First, today the Delay scheduling process is being terminated on shutdown and being re-initialized on startup. This means that even if a shutdown/startup action tries to use a delay that will fail/block indefinitely? Second, what happens with race conditions between the startup and the delay process? If the shutdown is in the middle of terminating the delay process and the delay process gets suddenly activated? stopTimerEventLoop "Stop the timer event loop" timerEventLoop ifNotNil: [ timerEventLoop terminate ]. timerEventLoop := nil. Maybe before terminating the timerEventLoop we need to suspend it? That will at least atomically (primitive) remove the process from the ready list and avoid it from being activated again, no? In any case, I see no good in letting a delay work on startup. That is far too low level and the system would be in a far too unstable state to run any code other than the startup itself. > btw, what happens if an error occurs inside valueUnpreemptively? > Does the normal priority debugger still get to run? > > cheers -ben > > On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi all, >> >> I'm proposing a kind-of critical change that I believe is very good for >> the health of the system: I want that the startup of the system runs in >> maximum priority and becomes non-interruptable. >> >> Right now, when you save your image, the shutdown and startup are run in >> the same priority than the process that triggered the save (usually the ui >> or the command line, priority 40). This can cause lots of problems and race >> conditions: processes with higher priorities can interrupt the >> shutdown/startup and try to do something while the system is unstable. As a >> side effect also, when you use extensively the command line, you start >> stacking startup contexts from old sessions: >> >> ... >> session 3 ctxt 4 <- This guy makes a save and a new session starts >> session 3 ctxt 3 >> session 3 ctxt 2 >> session 3 ctxt 1 >> session 2 ctxt 4 <- This guy makes a save and a new session starts >> session 2 ctxt 3 >> session 2 ctxt 2 >> session 2 ctxt 1 >> session 1 ctxt 4 <- This guy makes a save and a new session starts >> session 1 ctxt 3 >> session 1 ctxt 2 >> session 1 ctxt 1 >> >> Old contexts are never collected, and the objects they referenced neither. >> >> To fix these two problems I propose to do every image save/session start >> in a new process in maximum priority. That way, other process should not be >> able to interrupt the startup process. Moreover, every session >> shutdown/startup should happen in a new clean process, to avoid the session >> stacking. >> >> For normal users, this should have no side effect at all. This change >> will have a good impact on people working on the debugger and the stack >> such as fueling-out the stack because they will have a cleaner stack. >> >> There is however a side-effect/design point to consider: startup actions >> should be quick to run. If a startup action requires to run a long-running >> action such as starting a server or managing a command line action, that >> should run in a separate process with lower priority (usually >> userPriority). In other words, the startup action should create a new >> process managing its action. >> >> If you want to review (and I'd be glad) >> >> Pull request: https://github.com/pharo-project/pharo/pull/198 >> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >> Current validation going on: https://ci.inria.fr/pharo-ci-j >> enkins2/job/Test%20pending%20pull%20request%20and%20branch% >> 20Pipeline/view/change-requests/job/PR-198/ >> >> Guille >> >> -- >> >> >> >> Guille Polito >> >> >> Research Engineer >> >> French National Center for Scientific Research - *http://www.cnrs.fr* >> <http://www.cnrs.fr> >> >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 15, 2017

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

by Craig Latta

Hi Frank-- > > > ...especially if their sources MUST be closely connected with > > > existing Smalltalk code, which does not run in the client like > > > all the data-driven model definitions etc that I already have > > > > There is no such requirement. > > Of course, there is, actually it's an absolute necessity in my case. Oh, I misunderstood you. I thought you were saying that such a coupling was a bad thing; I didn't realize it's a constraint you already have. Anyway, Caffeine is a distributed system. As long as your existing code can use WebSockets, you can use remote messaging between your code and the object memories running in web browsers. The Snowglobe remote UI examples, for example, have object memories running in the AWS cloud which can send messages to objects in a web browser, modifying that web browser's DOM objects. > > ...at the moment my UI is Mozilla's A-Frame 3D virtual reality > > framework, at 90 frames per second. > > Well, what I have seen from the demos, the responsiveness to the > cursor alone is so very far away from being acceptable... That must have been the first Smalltalk Morphic demo, in which Morphic had full unoptimized control of the cursor. Since then, I've made UIs that use the Zebkit UI framework, morphic.js from the Snap project, A-Frame, and pure HTML/CSS. As it turns out, I now always use the web browser's built-in cursor handling for the normal case, even with Smalltalk Morphic, so one gets the native OS cursor handling speed. > ...that I only believe, what you are writing, when I have seen a > real-world JavaScript UI based on your system. Sorry, over the years, > from bad experiences and one's own mistakes, I have become very > skeptical and even more careful. Sure, no worries; as older demos are replaced with newer ones this stuff will be obvious. > > > and it's impossible to port my >10.000 framwork and application > > > classes to Squeak. > > > Caffeine can use Pharo, Squeak, or Cuis. > > Well, my Smalltalk code is in neither of these and it would cost many > months of work and the loss of very essential tools to port this to > any of your supported systems. Oh, since you're not using Pharo, if were were to continue this conversation it should be off-list in private email. Anyway, you could use Caffeine's remote UI server component in your Smalltalk environment, and just use web browsers for the UI. I'm currently adapting the remote messaging parts to all the other Smalltalks. > However, *I see one advantage in your approach*, assuming that no > Smalltalk source code must be sent to the client (I have no info > about that) and this is in the fact that Smalltalk byte code is, of > course, a much better protection of IPR than any obfuscated > JavaScript could ever offer. But the price for this advantage would > be far to high, as far as I can currently tell. No, no Smalltalk code need be sent to the client, although you always have the option of sending remote messages. thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco craig(a)blackpagedigital.com voice through 2017-09-12: + 1 510 833 5799 (SMS ok) +31 20 893 2796 (no SMS)

Aug. 15, 2017

Re: [Pharo-dev] @About posting here

by Guillermo Polito

Hi Frank, Le mar. 15 aoÃ»t 2017 Ã 22:11, Frank-B <frank.berger.software(a)web.de> a Ã©crit : > @about this forum at world.st I never use that website to interact with the mailing list. Most people I know use regular mail as me. In practice, we use that forum as conversation backup. It's also practical because Google indexes it (in contrast to our non Google groups mailing list). > <http://world.st> > > I have a lot of forum experience from studying "forum psychology and > sociology" in three different language and in various forums run by very > different software but I have never come about any system that is *nearly > as > crappy, sick and idiotic as this one here*: > > - various message don't show up here > - masses of emails that I am not interested in are polluting my email > client > (and I will stop this silly downloading tonight by directing them straight > into the delete folder) > - and one is never informed if there is any reply to one's posting, which > is > standard on almost all forums and comment part of blogs > - and there is no chance to directly reply to some post > - thus there is no branching of the subjects > - which makes following a sib-thread most difficult > > I am neither going to write answers in my email clent, not will I continue > to pollute my system with 99% unwanted messages. > > I just ask myself: Why are Smalltalk people with the "best" IDE of all > using > such a crappy system!? > > Mailing lists are something - in my view - soooo much outdated and just a > pain in the....! > Well, currently the communication of this community is split between the mailing list (not the online forum I assume you use) and a discord group. We tried slack before but we abandoned it because it loses conversation history unless you pay. Actually, discord has far more interactions. But mailing lists are for perenne conversations. Those who like both are subscribed to both. Guille > Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It > would be the normal reaction of a crowd if a new sheep dares to criticise > what the crowd has been doing for long. I don't care! > > Regards > Frank > > > > > -- > View this message in context: > http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 15, 2017

[Pharo 70 ] build 36 - PR 204 Improve-comment-of-SmallDictionary

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/20091/Improve-comment-of-SmallDictionary https://github.com/pharo-project/pharo/pull/204

Aug. 15, 2017

Re: [Pharo-dev] @Craig Latta

by Frank-B

Hello Craig, your answer to my posting to you does not show up here and I only accidentally detected it in the flood of unwanted messages that came is. See my frustration posting above. I accidentally saw just your reply come in. This is why I am answering here to the most important points. I hope you receive this answer. I wrote: > ...especially if their sources MUST be closely connected with existing > Smalltalk code, which does not run in the client like all the > data-driven model definitions etc that I already have You answered: > There is no such requirement. Of course, there is, actually it's an absolute necessity in my case. Almost all UI components relate to some definition data, which exist in my main Smalltalk environment. From this data the DDL is generated, the models created, this data handles at run-time the instance variables, avoid getters and setters, and a huge lot more. It's ALL ONLY in ONE central place, of course. No dedundancies! This also handles versions and different configs. The UI is just a slightly enhanced extension to the data-definded models in the MVC concept. And all my models are defined ONLY by data. It would be insane to douplicate this data into the UI parts! I wrote: > the responsivness of such a solution in the browser must always be far > slower than any "normal" browser UI You answered: > That's not true. For example, at the moment my UI is Mozilla's > A-Frame 3D virtual reality framework, at 90 frames per second. Well, what I have seen from the demos, the responsiveness to the cursor alone is so very far away from being acceptable that I only belive, what you are writing, when I have seen a real-word JavaScript UI based on your system. Sorry, over the years, from bad experiences and one's own mistakes, I have become very sceptical and even more careful. I wrote: > and it's impossible to port my >10.000 framwork and application > classes to Squeak. You answered: > Caffeine can use Pharo, Squeak, or Cuis. Well, my Smalltalk code is in neither of these and it would cost many months of work and the loss of very essential tools to port this to any of your supported systems. That is out of any discussion. Such an investment would never pay back and AFAIK a lot of features are missing in Pharo to substitute my current environment (I couldn' be drunk enough to ever consider Squeak alone because of its outregeous UI). However, *I see one advantage in your approach*, assuming that no Smalltalk source code must be sent to the client (I have no info about that) and this is in the fact that Smalltalk byte code is, of course, a much better protection of IPR than any obfuscated JavaScript could ever offer. But the price for this advantage would be far to high, as far as I can currently tell. So, thank you for responding. I tink we can close the case at least for the foreseable future (and I can't wait, I need some working solution during winter 2017/18). Good luck with your development! Best regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] @About posting here

by Frank-B

@about this forum at world.st I have a lot of forum experience from studying "forum psychology and sociology" in three different language and in various forums run by very different software but I have never come about any system that is *nearly as crappy, sick and idiotic as this one here*: - various message don't show up here - masses of emails that I am not interested in are polluting my email client (and I will stop this silly downloading tonight by directing them straight into the delete folder) - and one is never informed if there is any reply to one's posting, which is standard on almost all forums and comment part of blogs - and there is no chance to directly reply to some post - thus there is no branching of the subjects - which makes following a sib-thread most difficult I am neither going to write answers in my email clent, not will I continue to pollute my system with 99% unwanted messages. I just ask myself: Why are Smalltalk people with the "best" IDE of all using such a crappy system!? Mailing lists are something - in my view - soooo much outdated and just a pain in the....! Now: Hunt me, shout at me, call me whatever you want! That's fine by me. It would be the normal reaction of a crowd if a new sheep dares to criticise what the crowd has been doing for long. I don't care! Regards Frank -- View this message in context: http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 15, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Eliot Miranda

> On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> You hit several birds with one single mail. >> >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >> > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling >> > the syntax is an interesting one that I hadnât thought about. >> > >> > Personally, I find having too many similar syntaxâs confusing - contributing >> > to things is hard enough - having to remember that its !! Instead of ## and >> > ââ instead of ** is just frustrating for me. >> >> +1 >> >> Not only for docs, most platforms like Slack/Discord share the syntax, >> so now I'm getting "muscle memory" when typing literals using the >> backtick (`) character, quoting with > or pasting snippets using ``` > > +1. So I've posted this before... > https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… > describing that "The only strategy in getting people to switch to your product is to eliminate barriers" > > But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... > > So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." > Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). +1! > > cheers -ben > >> >> > Sure, maybe we were first with Pillar, but for me, lots of programming is in >> > other languages, and I use Smalltalk where I can, and a hybrid of multiple >> > languages and projects is often the reality - so a lowest common denominator >> > of Markdown is just easier. The fact that we are quite close to what our >> > colleagues in other languages use (regardless of what Python has chosen), is >> > quite interesting. >> >> This helps building "bridges" with other communities. >> > > > > >> >> The language as a means of exchange is always the lowest common denominator. >> As long as it's "efficient enough" then I vote to use what other >> communities use. >> >> > That said, if the community wants to stick to its gunâs thats fine - I will >> > probably still investigate how to use Commonmark for myself, and will still >> > contribute to Pillar docs where I can (and curse history) - but I think we >> > are long better off trying to join emerging standards where we can >> > particularly if they arenât our core language thing. And it just makes it >> > less frictionless for ourselves and newcomers. >> >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's >> important to be aware of this bias and think more than once whether >> eating our own dogfood adds value to the core of what Pharo brings. >> >> I think we missed some good years fighting with our own SCM and in the >> end git (or any other file based SCM) prevailed, even when it has >> limitations. >> >> Pareto (80-20) for everything non-core business should be a guide. >> >> > Of course, if we were to move, we would need to translate a lot of quality >> > docs to a new format - but I would be up for contributing to that if that >> > was a deciding factor. >> >> There are some Markdown exporters AFAIK, or it could be written. >> >> >> Esteban A. Maringolo >> >

Aug. 15, 2017

Re: [Pharo-dev] Issue 20309 - Startup should run always in a fresh process

by Eliot Miranda

Hi Ben, > On Aug 15, 2017, at 6:25 AM, Ben Coman <btc(a)openinworld.com> wrote: > > In case any of the shutdown/startup scripts use a delay, now or in the future, > I'd first try at highestPriority-1 to avoid influence on the DelayScheduler. +1. In fact I'd raise it to no more than lowIOPriority - 1. > but then Eliot's suggestion to valueUnpreemptively may avoid that anyway. It does not. > > btw, what happens if an error occurs inside valueUnpreemptively? > Does the normal priority debugger still get to run? Once the notifier is opened the process is suspended. So startup will not complete, just as is the case now. But the exception is logged, so it's no longer invisible. BTW, on a related note, on snapshot, the primitive should not do a GC. Instead, the system should go a GC and allow any resulting finalization complete before the snapshot and well before the quit. Consider a buffered file that is flushed on finalization. This must happen before the snapshot. The GC in the snapshot is fine for ensuring the snapshot file is compact but very wrong for adding things to the finalization queue. > cheers -ben > >> On Mon, Aug 14, 2017 at 6:42 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Hi all, >> >> I'm proposing a kind-of critical change that I believe is very good for the health of the system: I want that the startup of the system runs in maximum priority and becomes non-interruptable. >> >> Right now, when you save your image, the shutdown and startup are run in the same priority than the process that triggered the save (usually the ui or the command line, priority 40). This can cause lots of problems and race conditions: processes with higher priorities can interrupt the shutdown/startup and try to do something while the system is unstable. As a side effect also, when you use extensively the command line, you start stacking startup contexts from old sessions: >> >> ... >> session 3 ctxt 4 <- This guy makes a save and a new session starts >> session 3 ctxt 3 >> session 3 ctxt 2 >> session 3 ctxt 1 >> session 2 ctxt 4 <- This guy makes a save and a new session starts >> session 2 ctxt 3 >> session 2 ctxt 2 >> session 2 ctxt 1 >> session 1 ctxt 4 <- This guy makes a save and a new session starts >> session 1 ctxt 3 >> session 1 ctxt 2 >> session 1 ctxt 1 >> >> Old contexts are never collected, and the objects they referenced neither. >> >> To fix these two problems I propose to do every image save/session start in a new process in maximum priority. That way, other process should not be able to interrupt the startup process. Moreover, every session shutdown/startup should happen in a new clean process, to avoid the session stacking. >> >> For normal users, this should have no side effect at all. This change will have a good impact on people working on the debugger and the stack such as fueling-out the stack because they will have a cleaner stack. >> >> There is however a side-effect/design point to consider: startup actions should be quick to run. If a startup action requires to run a long-running action such as starting a server or managing a command line action, that should run in a separate process with lower priority (usually userPriority). In other words, the startup action should create a new process managing its action. >> >> If you want to review (and I'd be glad) >> >> Pull request: https://github.com/pharo-project/pharo/pull/198 >> Fogbugz issue: https://pharo.fogbugz.com/f/cases/20309 >> Current validation going on: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… >> >> Guille >> >> -- >> >> Guille Polito >> >> Research Engineer >> French National Center for Scientific Research - http://www.cnrs.fr >> >> >> Web: http://guillep.github.io >> Phone: +33 06 52 70 66 13 >

Aug. 15, 2017