- Pharo-users - lists.pharo.org

Is Package Browser kaputt ?

by Dimitris Chloupis

I try to open Package Browser on Ubuntu with alpha+vmLatest pharo set up and gives me an error Also last time I checked it refused to add my CPPBridge project even though I added over a day ago.... does not like my code ? Thats rude :D Dictionary>>errorKeyNotFound: [ self errorKeyNotFound: key ] in Dictionary>>at: in Block: [ self errorKeyNotFound: key ] Dictionary>>at:ifAbsent: Dictionary>>at: IRPushClosureCopy>>indexForVarNamed: IRTranslatorV2>>visitPushTemp: IRPushTemp>>accept: IRTranslatorV2(IRVisitor)>>visitNode: IRTranslatorV2>>visitInstruction: [ :instr | self visitInstruction: instr ] in IRTranslatorV2(IRVisitor)>>visitSequence: in Block: [ :instr | self visitInstruction: instr ] OrderedCollection>>do: IRSequence>>do: IRTranslatorV2(IRVisitor)>>visitSequence: IRTranslatorV2>>visitSequence: IRSequence>>accept: IRTranslatorV2(IRVisitor)>>visitNode: [ :each | self visitNode: each ] in IRTranslatorV2(IRVisitor)>>visitNodes: in Block: [ :each | self visitNode: each ] SortedCollection(OrderedCollection)>>do: IRTranslatorV2(IRVisitor)>>visitNodes: IRTranslatorV2>>visitSequences: IRTranslatorV2>>visitMethod: IRMethod>>accept: IRTranslatorV2(IRVisitor)>>visitNode: IRMethod>>generate: IRMethod>>compiledMethodWith: IRMethod>>compiledMethod IRMethod>>instructionForPC: RBMethodNode>>sourceNodeForPC: CompiledMethod>>sourceNodeForPC: Context>>sourceNodeExecuted

Nov. 10, 2016

Re: [Pharo-users] AWS libraries

by Esteban Lorenzano

I know about this: https://github.com/newapplesho/aws-sdk-smalltalk <https://github.com/newapplesho/aws-sdk-smalltalk> Esteban > On 10 Nov 2016, at 12:45, Norbert Hartl <norbert(a)hartl.name> wrote: > > What libraries exist these days for amazon services? I may need a library for SNS service so is there anybody working on it? > > thanks, > > Norbert

Nov. 10, 2016

2nd Call for papers - <Programming> 2017

by Tim Molderez

<Programming> 2017 : The Art, Science, and Engineering of Programming April 3-6, 2017, Brussels, Belgium http://2017.programming-conference.org We started a new conference and journal focused on everything to do with programming, including the experience of programming. We call the conference <Programming> for short. Paper submissions and publications are handled by the journal. Accepted papers must be presented at the conference. ******************************************************** CALL FOR PAPERS ******************************************************** <Programming> 2017 accept scholarly papers including essays that advance the knowledge of programming. Almost anything about programming is in scope, but in each case there should be a clear relevance to the act and experience of programming. **PAPER SUBMISSIONS**: December 1, 2016 We accept submissions covering several areas of expertise. These areas include, but are not limited to: â¢ General-purpose programming â¢ Distributed systems programming â¢ Parallel and multi-core programming â¢ Graphics and GPU programming â¢ Security programming â¢ User interface programming â¢ Database programming â¢ Visual and live programming â¢ Data mining and machine learning programming â¢ Interpreters, virtual machines and compilers â¢ Modularity and separation of concerns â¢ Model-based development â¢ Metaprogramming and reflection â¢ Testing and debugging â¢ Program verification â¢ Programming education â¢ Programming environments â¢ Social coding ******************************************************** IMPORTANT DATES ******************************************************** â¢ Research paper submissions: December 1, 2016 â¢ Research paper first notifications: February 1, 2017 â¢ Research paper final notifications: March 7, 2017 â¢ Workshop proposals: November 15, 2016 â¢ European Lisp Symposium submissions: January 30, 2017 **new** â¢ Salon des RefusÃ©s workshop submissions: February 1, 2017 **new** â¢ LASSY 2017 workshop submissions: January 13, 2017 **new** â¢ PX 2017 workshop submissions: February 4, 2017 â¢ Poster abstract submissions: January 16, 2017 ******************************************************** ORGANIZATION ******************************************************** General Chair: Theo D'Hondt, Vrije Universiteit Brussel Local Organizing Chair: Wolfgang De Meuter, Vrije Universiteit Brussel Program Chair: Crista V. Lopes, University of California, Irvine Organizing Committee: JÃ¶rg Kienzle (workshops), McGill University Hidehiko Masuhara (demos), Tokyo Institute of Technology Ralf LÃ¤mmel (contest), University of Koblenz-Landau Jennifer Sartor (posters), Vrije Universiteit Brussel Tobias Pape (web technology), HPI - University of Potsdam Tim Molderez (publicity), Vrije Universiteit Brussel Program Committee: Andrew Black, Portland State University Shigeru Chiba, University of Tokyo Yvonne Coady, University of Victoria Robby Findler, Northwestern University Lidia Fuentes, Universidad de MÃ¡laga Richard Gabriel, IBM Research Elisa Gonzalez Boix, Vrije Universiteit Brussel Jeff Gray, University of Alabama Robert Hirschfeld, HPI - University of Potsdam Roberto Ierusalimschy, PontifÃcia Universidade CatÃ³lica do Rio de Janeiro JÃ¶rg Kienzle, McGill University Hidehiko Masuhara, Tokyo Institute of Technology Sasa Misailovic, University of Illinois at Urbana-Champaign Guido Salvaneschi, Technische UniversitÃ¤t Darmstadt Mario SÃ¼dholt, Ecole des mines de Nantes Jurgen Vinju, Centrum Wiskunde & Informatica Tijs van der Storm, Centrum Wiskunde & Informatica ******************************************************** <Programming> 2017 is kindly supported by: ACM in-cooperation ACM SIGPLAN in-cooperation ACM SIGSOFT in-cooperation AOSA Vrije Universiteit Brussel ******************************************************** For more information, visit http://2017.programming-conference.org

Nov. 10, 2016

OopluCon 2017

by Chris Cunnington

http://www.ooplu.com/ Chris

Nov. 10, 2016

Re: [Pharo-users] connecting to remote pharo 5 image on server.

by Denis Kudriashov

Hi 2016-11-09 16:52 GMT+01:00 itay yahalom <itay.yahalom(a)gmail.com>: > Hi all, > is there any RFB or VNC to use with pharo 5? > i want to connect to my pharo 5 environment remotly, the image sit on a > linux server that is hosted on digital-ocean . > all of this is so i can control and see if something go bad with the image > (and debug it) or that i can use pharo to check the mongodb data. > any help will be great . > Look also at this option: http://dionisiydk.blogspot.fr/2016/07/remote-debugging-tools-is-ready.html

Nov. 10, 2016

Re: [Pharo-users] connecting to remote pharo 5 image on server.

by Pierce Ng

On Wed, Nov 09, 2016 at 05:52:43PM +0200, itay yahalom wrote: > is there any RFB or VNC to use with pharo 5? > i want to connect to my pharo 5 environment remotly, the image sit on a > linux server that is hosted on digital-ocean . Yes there is an RFB server implemented in Smalltalk. The GUI interace may not work in Pharo 5 but you can execute the server in a playground, I've written some blog posts on this topic, at http://www.samadhiweb.com/tags/RFB. Most recent post on the topic is from 2014, but the blog _is_ currently powered by a Pharo 5 instance with a running RFB server. Pierce

Nov. 10, 2016

AWS libraries

by Norbert Hartl

What libraries exist these days for amazon services? I may need a library for SNS service so is there anybody working on it? thanks, Norbert

Nov. 10, 2016

Re: [Pharo-users] Can pharo association web page point to association.pharo.org, like the consortium one?

by Norbert Hartl

> Am 10.11.2016 um 09:44 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > >> On 5 Nov 2016, at 12:31, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> Current Status: >> >> - SPF record DONE, mails are now send from @association.pharo.org >> - DNS setup now uses association.pharo.org <http://association.pharo.org/> for normal viewing, just forms forward to https://pharo. <https://pharo.assocation/>wildapricot.org <http://wildapricot.org/> >> This will change as soon as the SSL certificate setup is completed, which will be next week. >> > > > SSL setup is DONE. > > https://association.pharo.org <https://association.pharo.org/> > > > The site is now fully operational. > great! Norbert

Nov. 10, 2016

Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL

by Dimitris Chloupis

> > Well, a while before that, i wrote own lobotomized smalltalk > implementation in C and started generating bindings to Ogre3D engine. I > even had certain success with it, but then i started grand-rewriting of VM > and abandoned it. > That was before i switched to Squeak, then Pharo. So, your incentives > quite familiar to me :) > I was quite fun journey, and i learned a lot while doing it.. especially > about smalltalk. > > I have no interest into implementing Smalltalk at C side , neither my purpose is education, quite the contrary I try to find way to utilize Pharo the best way possible without compromising on performance > I don't understand why people find assembly scary or mind-boggling? I > dived into assembly few months after i learned my first programming > language, it was Zilog 8-bit CPU. A marvelous gem :) > And this was always fascinating to feel that you can control the > computer's behaviour down to a tiniest detail. We were even researching > what certain i/o ports and interrupts were responsible for by setting > different bits/bytes here and there and see what happen. > Because if you don't understand something down to the tiniest detail - you > cannot be sure that what you doing will work, or work optimally. > So i find it frustrating that most of programmers don't know and not even > thinking about touching assembly. Because it very simple, straightforward > and megalomaniac-rewarding :) > -- > Best regards, > Igor Stasenko. > Assembly is hard, just compare its hello world with the hello world of other progamming languages. Its just insane. The thing is that because we started on early , we experienced assembly when it used to be fairly simple. I started with an Amstrad CPC 6128 with 128 kb of ram and 4 mhz CPU, it uses Z80 assembly which is fairly simple even when compared to Pharo. Modern Assembly however have grown on complexity because it depend on the complexity of the hardware. Personally I don even like to call it a programming language , just beautified machine code. I agree though Assembly is a lot of fun and a great source of knowledge.

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by phil＠highoctane.be

On Thu, Nov 10, 2016 at 10:12 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Dale, > > 2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > : > >> >> >> On 11/8/16 7:09 AM, Thierry Goubier wrote: >> >> Hi Dale, >> >> 2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com >> >: >> >>> [ snip ... ] >>> >>> yes I think this is the area where a Metallo Project Browser comes into >>> play. The technology for committing the dirty packages in a a >>> ConfigurationOf has been around for quite awhile, but a tool that unifies >>> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped >>> out of the wood work ... >>> >> >> I'm having some issues with the scripting approach of Metacello, for >> that. Just manipulating a baseline in the Metacello registry (locking it) >> seems to be like writing a compiler code generation item: write a Metacello >> script ;) (Metacello>>#lock contains interesting code). >> >> I think I agree:) ... that is why i am talking about a tool ... >> developers shouldn't have to pass around workspaces to load and manipulate >> projects .. a project tool can partially automate the process, but I >> believe that there needs to be a "load spec" object that can be passed >> around and massaged by code instead of requiring a user to edit a Smalltalk >> workspace ... it's what I do in tODE ... the only times I have to write >> Smalltalk load scripts is when I work in Pharo :) >> > > Agreed. I would just like to find out which object can be used to act upon > (can I call lock on a Metacello project spec... apparently not :))... I'm > not too keen on adding another layer on top of it, first because I'm not > that found of unneeded layers, second because it may mean a significant > rewrite of the environment (have dozens of methods like MyLayer>>#load > which is just a call to Metacello load) to get something that starts > working. > > I'm not in a position to impose large scale changes in the Pharo > ecosystem; it's the consortium role to take and impose such choices. I can > only, like GitFileTree, inject something at a lower level that allow people > to complement and experiment with... > >> >> >> I will repeat that I don't think Pharo should do exactly what I've done >> with tODE, but a Metacello Project Browser and some sort of "load spec" >> object that is shared amongst a cluster of images is something that needs >> to be seriously considered ... >> > > I'm really willing to also make something helping to work with Baselines / > Configurations because I think they present a significant complexity > barrier to the proper use of Metacello features, and I don't see any path > avoiding us to write those, given how complex it may be. > Now a BaselineOf is a ConfigurationOf but such things cannot be put in the Catalog because well, there is some incompatibility happening. Getting BaselineOf usable right away would be a small step but a great step. I find myself having to write a BaselineOf for the Git repo and a ConfigurationOfXXX usign the old scheme to be put in the Catalog and pointing to the BaselineOf. Could someone point to the reason why? > >> >> >>> >>> >>> What is a bit annoying, really, is this talk of rewriting everything >>> where some of the pieces (the project browsing you're talkin about, for >>> example) is already there in the image, just not exposed. >>> >>> Well I am annoyed as well .. I would say that perhaps we are in >>> screaming agreement ... I've said that I don't think it's a lot of work to >>> do the project-centric tool. but a project-centric tool that encompasses >>> both ConfigurationOf and BaselineOf will expose the features that "are >>> already there" >>> >>> >>> I'm trying to code a little something for that... stay tuned for a >>> screenshot soon. >>> >>> Cool:) >>> >> >> And here it is! I'm still fighting with the Metacello lock / unlock thing. >> >> [image: Images intÃ©grÃ©es 1] >> >> If Pharo was more really modular in configurations and baselines, then I >> would see more things into the registry and I could group packages based on >> that (instead of having to prepare a ad-hoc classification for my my >> browser). >> >> Yes this is headed in the right direction ... I am in Argentina this week >> so it isn't easy for me to do much collaboration, but I would love to help >> you with your lock problem next week ... For example ... you do not want to >> directly expose the Metacello registry as there are "hybrid projects" where >> a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs >> to take precedence (I have code for resolving this) and I strongly suggest >> that the Project Browser not be built-into the Class Browser, but be a >> separate tool like the CataLogBrowser ... but this is just a suggestion --- >> a separate tool dedicated only to loaded Projects and unloaded Projects of >> interest allows one to get a very quick overview of what is in the project >> or not and when version skew pops up, one can easily see the affected >> projects ... embedding this kind of information in the code browser can >> make it hard to get the overview and if you choose to live with version >> skew can be annoying to ignore .... again these are just my thoughts .. >> > > I'm of a different mind on this. Giving access to the Metacello registry > explains well to me what is happening in the system; as long as the GUI > accelerate a significant subset of the common operations, then I'll > consider it good enough and have it working on a short time frame. > Already having the GTPlayground showing an inspector after loading is nice these days. Before it was more convoluted to understand what was going on. The inspector panes kind of rewrite things their way but still nice to have. > Otherwise, you end up with projects like libgit / Iceberg, which are > taking significantly longer to reach a better solution... Exposing the > exponential time needed to reach the perfect solution. > What is Iceberg trying to solve exactly? Ah, and I found why my Pharo5 image explodes when using GitFileTree on Windows: because of ProcessWrapper trying to use git which is in turn not in the path, and then boom. > > I also hate information duplication: why do I have to write a complex > project spec where most (all?) of it has to be rewritten in a different > form in a BaselineOf? Same goes for the forks you described the other day: > why do I have to write in my project description the information I also > have to add inside the repository (an upstream remote) to manage updating > with the master project? > There is too much stuff to understand to get anything used by a layman. There isn't so much to do with tools like npm.js etc: write your json thing for the package, use semver and this is all looking logical. So that one can get a junior dev handle it in a day. Try that with what we have. Phil > > For version skew, I must be a bit like git designers on that. It has to be > an action (a git pull), and this action is required in git anyway (git pull > upstream / git pull origin) .. I have no opinion on whether a GUI has to > automatically check that everytime I open the project browser. > > >> >> Regardless I think you are definitely headed in the right direction and >> it isn't all that much work ... yet:) >> > > I need to keep it reasonable to be able to tackle it :) > > Thierry > > >> >> >> Dale >> > >

Nov. 10, 2016