September 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #794: 4760-Debugger-we-can-not-step-into-methods-anymore

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #794 was: SUCCESS. The Pull Request #4762 was integrated: "4760-Debugger-we-can-not-step-into-methods-anymore" Pull request url: https://github.com/pharo-project/pharo/pull/4762 Issue Url: https://github.com/pharo-project/pharo/issues/4760 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2019

Re: [Pharo-dev] A call for a library to script github.com

by Christopher Fuhrman

I didn't mention it in my blog post, but the GraphQL API Explorer [1] is also super useful to do code completion, etc., because constructing queries is not always that intuitive. I merely used copy/paste of the queries. It would be cool if Pharo could somehow integrate that tool. [1] https://developer.github.com/v4/explorer/ On Fri, 27 Sep 2019 at 06:23, ducasse <stepharo(a)netcourrier.com> wrote: > Thanks chris. > Alexandre and Juan Pablo did an implementation of GraphQL some years ago. > May be you want to check and join effort. > > Stef > > On 27 Sep 2019, at 00:56, Chris Muller <asqueaker(a)gmail.com> wrote: > > GraphQL is da bomb, I would definitely recommend writing a client to > access their v4 API. You may not even need it, but Squeak will have a full > GraphQL parser and document validation and processing engine real soon > now. It's completely stand-alone, no dependencies, and I've kept > portability in mind the entire time while developing it. Hopefully it'll > "just work" if dropped into Pharo. It has hundreds of tests so far, every > sentence in the spec is covered, so, you'll know. Status is, after 14 > months work, I'm allllmost done.. this is some of my best work ever.. > > - Chris > > On Thu, Sep 26, 2019 at 4:03 PM Brainstorms <wild.ideas(a)gmail.com> wrote: > >> Christopher Fuhrman posted this on his blog last March. (I ran across it >> looking for his LibC blog post.) >> >> This doesn't cover the scope of what you listed, but as sort of a "proof >> of >> concept" it does show a couple of ways that the GitHub API can be >> scripted. >> >> https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Sept. 27, 2019

[Pharo 8.0] Build #793: 4755-add-back-rangeForPCcontextIsActiveContext

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #793 was: SUCCESS. The Pull Request #4756 was integrated: "4755-add-back-rangeForPCcontextIsActiveContext" Pull request url: https://github.com/pharo-project/pharo/pull/4756 Issue Url: https://github.com/pharo-project/pharo/issues/4755 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2019

[Pharo 8.0] Build #792: 2716-Clean-Editor-method-

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #792 was: FAILURE. The Pull Request #4680 was integrated: "2716-Clean-Editor-method-" Pull request url: https://github.com/pharo-project/pharo/pull/4680 Issue Url: https://github.com/pharo-project/pharo/issues/2716 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2019

Re: [Pharo-dev] A call for a library to script github.com

by ducasse

Thanks chris. Alexandre and Juan Pablo did an implementation of GraphQL some years ago. May be you want to check and join effort. Stef > On 27 Sep 2019, at 00:56, Chris Muller <asqueaker(a)gmail.com> wrote: > > GraphQL is da bomb, I would definitely recommend writing a client to access their v4 API. You may not even need it, but Squeak will have a full GraphQL parser and document validation and processing engine real soon now. It's completely stand-alone, no dependencies, and I've kept portability in mind the entire time while developing it. Hopefully it'll "just work" if dropped into Pharo. It has hundreds of tests so far, every sentence in the spec is covered, so, you'll know. Status is, after 14 months work, I'm allllmost done.. this is some of my best work ever.. > > - Chris > > On Thu, Sep 26, 2019 at 4:03 PM Brainstorms <wild.ideas(a)gmail.com <mailto:wild.ideas@gmail.com>> wrote: > Christopher Fuhrman posted this on his blog last March. (I ran across it > looking for his LibC blog post.) > > This doesn't cover the scope of what you listed, but as sort of a "proof of > concept" it does show a couple of ways that the GitHub API can be scripted. > > https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html <https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html> > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >

Sept. 27, 2019

[Pharo 8.0] Build #791: 4745-OSSDL2-is-ignoring-characters-entered-with-AltGr

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #791 was: FAILURE. The Pull Request #4747 was integrated: "4745-OSSDL2-is-ignoring-characters-entered-with-AltGr" Pull request url: https://github.com/pharo-project/pharo/pull/4747 Issue Url: https://github.com/pharo-project/pharo/issues/4745 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2019

Re: [Pharo-dev] A call for a library to script github.com

by Alexandre Bergel

Hello, We have put a significant amount of effort on having an implementation of GraphQL for Pharo and VisualWorks. It even has a booklet. https://github.com/OBJECTSEMANTICS/GraphQL <https://github.com/OBJECTSEMANTICS/GraphQL> Cheers, Alexandre > On Sep 26, 2019, at 7:56 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > > GraphQL is da bomb, I would definitely recommend writing a client to access their v4 API. You may not even need it, but Squeak will have a full GraphQL parser and document validation and processing engine real soon now. It's completely stand-alone, no dependencies, and I've kept portability in mind the entire time while developing it. Hopefully it'll "just work" if dropped into Pharo. It has hundreds of tests so far, every sentence in the spec is covered, so, you'll know. Status is, after 14 months work, I'm allllmost done.. this is some of my best work ever.. > > - Chris > > On Thu, Sep 26, 2019 at 4:03 PM Brainstorms <wild.ideas(a)gmail.com <mailto:wild.ideas@gmail.com>> wrote: > Christopher Fuhrman posted this on his blog last March. (I ran across it > looking for his LibC blog post.) > > This doesn't cover the scope of what you listed, but as sort of a "proof of > concept" it does show a couple of ways that the GitHub API can be scripted. > > https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html <https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html> > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >

Sept. 26, 2019

Re: [Pharo-dev] [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

by Brainstorms

> Pay attention because Pharo could be better for supplanting bash. That was one of the first things I was evaluating Pharo on, to see its potential for replacing Bash (and therefore Lua, which I was also considering for this, initially; I'm one of those holdouts who hasn't learned Python -- I want "the real OOP" instead). But I have many years of programming Bash; I automate things. I really want Pharo to become my "handy tool" for this. And more. Now, there's this wrinkle: Pharo doesn't run in the same realm (e.g., Linux Userland) as the OS and associated tools I need to work with; it runs in its own container, akin to running in Docker or LXC. We call them "image files", but they're really like Docker or LXC containers -- only Pharo containers are plugged into a VM instead of a Linux kernel (so it's much better!). Also, the realm of Pharo is "Objectland", not an isolated filesystem such as LXC provides. But the principles are the same, and.. do I really want to learn Docker? The consequence of this is, "How do you cross the container boundary, as needed, to interact with 'the real world'?" And do so with ease? This is distinctly different from, say, file I/O, where you're almost doing the opposite in Pharo: Bringing (a representation of) the file system into the image in order to interact with it. I can't bring 'grep' into Pharo; I need to reach outside and launch 'grep', and interact with it, all from code executing in my image. Pharo shares this issue with Docker, but goes one further: Marshalling in/out of objects, because that's all there is "on the inside". These are interesting CS/IT issues, for sure... We depend on skillful IDE developers in the Pharo community to make it all work smoothly, almost invisibly. > To me Pharo is not really at the level I would like to. I have already gotten the feel for this. I started with an impression of "Pharo is Smalltalk that's modernized and mature, finally!" (having shifted from Squeak), to a more subtle feeling of "Wow, it's evolving (quickly!), there are many areas being improved, and still some things that are "in the rough". And that's okay; Rome wasn't built in a day and this is a major project. We're "rebuilding a 1970's sedan into a 21st Century electric autonomous car" sort of thing, and doing it while it's being driven. And successfully, too. So I will still recommend that engineers and developers spend time evaluating it. What language/IDE stands still anyway? They all evolve. > But this is my view. > Now we have nice binding to invoke shell and other like subOSProcess. > We should also progress on that front. I was frustrated a bit at first, but then I found Christopher Fuhrman's page on using 'LibC': https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html which shows how to "get a shell" on the host to run commands & access the environment variables (including returning stdout, stderr, and the $? result -- excellent). That seems to cover most needs, but I'm not sure if this is the "standard way to do it". It does seem pretty powerful, though. Then I found the "clap" project, https://github.com/cdlm/clap-st and then "Scale", https://github.com/guillep/Scale So I conclude that the ability is there, with more potential to be realized as things evolve. > To me Pharo is super good at manipulating complex data and object > and building nice abstraction. I get that! Bash is terrible at this, but it's super good at blending scripts with the OS evironment to make Userland tools work so seemlessly as part of your custom code they seem to be elements of the language. Now flip that around: How does Pharo fare at OS/environment interaction? We can't operate in a vacuum (unless we build, what? Single-player games?) > So I hope that you will not be disappointed. So far, I'm not; I'm inspired, if anything. Here's the list of what I consider to be the ideal capabilities of any language/programming environment, in increasing challenges. (And keep in mind that I don't come from a corporate IT background, shuttling & transforming data from cloud to cloud; I build code to automate machines, devices, instruments, operating systems, applications, processes, tools.. and every now & then processing the data. :^) 1.) I want to have full host file system capabilities. Not just read/write files, but manipulating the file system. Pharo seems to have this covered. 2.) I want to have good TCP/UDP capabilities. I want to act as a server to provide TCP sockets to connect to, act as a client and connect to servers using TCP, and be able to read and write UDP packets easily. Again, Pharo seems to provide this nicely. 3.) I want to be able to interact with the OS, the host environment, and tools and applications in the host. This includes being able to launch, monitor, and control processes -- and pass I/O in & out dynamically. In Bash, if I need complex pattern matching, I just "ask grep"; if I need programmatic editing of a file, I just "tell sed to do it". There's no hoops to jump through, and nothing to set up. Just "use the tool" and keep coding... I see ability here with Pharo. 4.) I want to be able to connect to compiled libraries of code and call them easily -- so that I can interact with devices as well as export behavior to pre-existing code. This is the Pharo uFFI. And I'll mention USB/serial use here; device control is Pharo IOT I'm told. I have yet to look at Pharo IOT, but I will be doing so soon, just as I will be immersed with the uFFI as I help with the docs and later the code. So I know Pharo can do this, too, yet it seems an area that's evolving. 5.) I want to be able to write applications that I can interact with from my host's command line. I want to write REPL apps, Linux filters, and the like. For example, I ought to be able to recreate 'grep' in Pharo (if I wanted to go to the trouble. Not really, but I should be able to do it). Most of my Bash and Lua scripts work at this level. With Pharo..? I'm not sure how well this can work. 6.) I want to create apps that have a nice, professional-looking mouse-driven GUI interface -- without the tedious nature of, say, Tk to build them. I know now that SpecUI answers that, to some degree of ease; but I'm not sure yet how well, as I need to run a tutorial & play with it. Pharo Launcher proves that these apps can be built. So I wonder, "How hard would it be to recreate Pharo Launcher?" Because of course, I want to deliver apps to my colleagues that work like running Pharo Launcher. So here it's a matter of "It can do it well, but how hard is it?" 7.) I want to create web apps, where my Pharo code, running in its container, is reached by a web browser or another app's code, over sockets (like accessing Docker microservices), whether it runs on the same host or a remote host. This is the ultimate -- it makes deployment, maintenance, access, and so forth much easier, enables scaling, redundancy, platform-independence, etc. My customers want this, but I can't give it to them currently. I know that Pharo can do this, and do it well. I like that the cognitive burden of learning web programming is significantly reduced with Pharo. (Here's a suggestion for Pharo: Make Pharo easily capable of plug-and-play in a Docker cluster. I want to make/deploy microservices built with Pharo, not Docker. The IT world seems to be swinging towards this, and if Pharo pursues this, perhaps it would be that breakout feature it needs.) 8.) Finally, I want to be able to create the client-side view/behavior/experience that my user sees and interacts with in a browser-as-my-GUI. I think this is Amber or PharoJS, and I know that this the summit of the mountain and most likely a separate skill area. I have never wanted to learn JavaScript, CSS, etc. but one can never get far from that, so I would leave this to the specialists. But being able to give them a Pharo environment to build these would be nice. I have no idea how ideal Amber/PharoJS is for making web pages... Where I am now, I have at least one language/IDE that gives me all but the last two capabilities on this list (and doesn't do #5 very well). But my primary IDE is closed-source and *expensive*. (I can pay several thousand more to a third-party vendor for an add-on that gives web control, but no one here wants to pay for that, even though many ask for the capability.) I want an open-source, platform-independent IDE instead. I started to think that Lua (with MANY add-on libraries) would cover enough of these "desirements", but I've always wanted to work in that pure OOP environment of Smalltalk. So I'm encouraged at all I've seen, because Pharo touches on all these capabilities. Not all perfectly, of course, but many very well. I don't think I'll be disappointed. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 26, 2019

Re: [Pharo-dev] A call for a library to script github.com

by Chris Muller

GraphQL is da bomb, I would definitely recommend writing a client to access their v4 API. You may not even need it, but Squeak will have a full GraphQL parser and document validation and processing engine real soon now. It's completely stand-alone, no dependencies, and I've kept portability in mind the entire time while developing it. Hopefully it'll "just work" if dropped into Pharo. It has hundreds of tests so far, every sentence in the spec is covered, so, you'll know. Status is, after 14 months work, I'm allllmost done.. this is some of my best work ever.. - Chris On Thu, Sep 26, 2019 at 4:03 PM Brainstorms <wild.ideas(a)gmail.com> wrote: > Christopher Fuhrman posted this on his blog last March. (I ran across it > looking for his LibC blog post.) > > This doesn't cover the scope of what you listed, but as sort of a "proof of > concept" it does show a couple of ways that the GitHub API can be scripted. > > https://fuhrmanator.github.io/2019/03/22/Using-GitHub-API-in-Pharo.html > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Sept. 26, 2019

Re: [Pharo-dev] A call for a library to script github.com

by Torsten Bergmann

https://github.com/guillep/github-api https://github.com/astares/GitHub-API > Gesendet: Donnerstag, 26. September 2019 um 19:01 Uhr > Von: "ducasse" <stepharo(a)netcourrier.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] A call for a library to script github.com > > Hi > > I know several people that would like to script from Pharo the github API. > - for the new review tools > - for posting bugs from pharo > - for dashboard > - for moose scripting > > There is also stargate and I would like to know whether there exist a library > to build on top to script github because I think that there is need for a nice lib > for that > > Stef > > > >

Sept. 26, 2019