February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Airbrake for Pharo

by Mariano Martinez Peck

On Tue, Feb 21, 2012 at 11:04 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Feb 21, 2012 at 11:01 PM, Lawson English <lenglish5(a)cox.net>wrote: > >> Have you looked at Spoon lately? >> >> > Yes, more than what you can imagine. My PhD topic is related to Spoon, I > have even checks its VM code and I have privatly discussed with Graig. > That being said, I don't see how Spoon can be related to what I am saying > in this email. > Ok...maybe I got it now. Related to the stuff of moving contexts and stuff between images right? if that's the case, then I appreciate the hint :) Now I am still waiting for comments on the Airbrake. > > Thanks > > >> L. >> >> >> On 2/21/12 2:48 PM, Mariano Martinez Peck wrote: >> >> Hi guys. In my post about "Moving contexts and debugger between images<http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-b…>" >> Francois recommend me to take a look to http://airbrakeapp.com/ >> I recommend you to take a look to the project to get an idea what it is. >> I argued that it was not open-source but then "renemendoza" pointed me out >> an open-source project which is API compliant with airbrake: >> https://github.com/errbit/errbit >> >> I think it could be a nice project to see how we can integreate that with >> Pharo. Could a Pharo-based app use such a tool? For example, can we add >> PharoDebug.log, crash.dump, etc etc? Do we need to write a client for >> Pharo? >> >> Would be able to upload Fuel serialized contexts so that someone can then >> debug in another image (with the limitations that it has) ? >> >> Cheers >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Feb. 21, 2012

Re: [Pharo-project] Airbrake for Pharo

by Mariano Martinez Peck

On Tue, Feb 21, 2012 at 11:01 PM, Lawson English <lenglish5(a)cox.net> wrote: > Have you looked at Spoon lately? > > Yes, more than what you can imagine. My PhD topic is related to Spoon, I have even checks its VM code and I have privatly discussed with Graig. That being said, I don't see how Spoon can be related to what I am saying in this email. Thanks > L. > > > On 2/21/12 2:48 PM, Mariano Martinez Peck wrote: > > Hi guys. In my post about "Moving contexts and debugger between images<http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-b…>" > Francois recommend me to take a look to http://airbrakeapp.com/ > I recommend you to take a look to the project to get an idea what it is. I > argued that it was not open-source but then "renemendoza" pointed me out an > open-source project which is API compliant with airbrake: > https://github.com/errbit/errbit > > I think it could be a nice project to see how we can integreate that with > Pharo. Could a Pharo-based app use such a tool? For example, can we add > PharoDebug.log, crash.dump, etc etc? Do we need to write a client for > Pharo? > > Would be able to upload Fuel serialized contexts so that someone can then > debug in another image (with the limitations that it has) ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Feb. 21, 2012

Re: [Pharo-project] Airbrake for Pharo

by Lawson English

Have you looked at Spoon lately? L. On 2/21/12 2:48 PM, Mariano Martinez Peck wrote: > Hi guys. In my post about "Moving contexts and debugger between images > <http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-b…>" > Francois recommend me to take a look to http://airbrakeapp.com/ > I recommend you to take a look to the project to get an idea what it > is. I argued that it was not open-source but then "renemendoza" > pointed me out an open-source project which is API compliant with > airbrake: https://github.com/errbit/errbit > > I think it could be a nice project to see how we can integreate that > with Pharo. Could a Pharo-based app use such a tool? For example, can > we add PharoDebug.log, crash.dump, etc etc? Do we need to write a > client for Pharo? > > Would be able to upload Fuel serialized contexts so that someone can > then debug in another image (with the limitations that it has) ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

Feb. 21, 2012

[Pharo-project] Airbrake for Pharo

by Mariano Martinez Peck

Hi guys. In my post about "Moving contexts and debugger between images<http://marianopeck.wordpress.com/2012/01/19/moving-contexts-and-debuggers-b…>" Francois recommend me to take a look to http://airbrakeapp.com/ I recommend you to take a look to the project to get an idea what it is. I argued that it was not open-source but then "renemendoza" pointed me out an open-source project which is API compliant with airbrake: https://github.com/errbit/errbit I think it could be a nice project to see how we can integreate that with Pharo. Could a Pharo-based app use such a tool? For example, can we add PharoDebug.log, crash.dump, etc etc? Do we need to write a client for Pharo? Would be able to upload Fuel serialized contexts so that someone can then debug in another image (with the limitations that it has) ? Cheers -- Mariano http://marianopeck.wordpress.com

Feb. 21, 2012

Re: [Pharo-project] Proposal: coverage tests

by Mariano Martinez Peck

That is just AMAZINGLY COOL. I cannot believe we can do that in 5 lines of code. WOW. Why nobody wrote a better test coverage report wich such backend? Alex, does you stuff do something with that? cheers On Tue, Feb 21, 2012 at 4:03 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Hi, > > what about to intrroduce tests that will test coverage of tests? Some > improved version of the code below. Are there some tool for Smalltalk > showing uncovered lines of code? There are such tools in Java world > :-) One little problem is that this code do not work on Linux because > of a VM error that cause test failures on CI server too. > > Cheers, > Pavel > > | class test trace classTrace result | > > class := Time. > test := TimeTest. > > trace := Dictionary new. > > thisContext runSimulated: [test suite run] contextAtEachStep: [ :current | > | cls sel methods bytecodes | > cls := current method methodClass. > sel := current method selector. > methods := trace at: cls ifAbsentPut: Dictionary new. > bytecodes := methods at: sel ifAbsentPut: Set new. > bytecodes add: current pc.] > > trace . > > result := String streamContents: [:s | > > classTrace := trace at: class ifAbsent: nil. > classTrace > ifNil: [ > s nextPutAll: 'Class ', class name, ' not called'; cr. ] > ifNotNil: [ > s nextPutAll: class name; cr. > class selectorsDo: [:sel | > | m usedBytecodes allBytecodes | > m := class >> sel. > usedBytecodes := (classTrace at: sel ifAbsent: Set > new) size. > allBytecodes := 0. > m symbolicLinesDo: [:pc :lineForPC | allBytecodes > := allBytecodes + 1 ].. > s tab; nextPutAll: sel; nextPutAll: ' - '; > nextPutAll: > (usedBytecodes / allBytecodes * 100) asFloat asString; nextPutAll: > '%'; cr. ]]. > ]. > result.. > > -- Mariano http://marianopeck.wordpress.com

Feb. 21, 2012

Re: [Pharo-project] Why do we use Pharo? a.k.a. rethinking Pharo marketing

by StÃ©phane Ducasse

esteban - I want a talk presenting your application for the pharo conference - yes you will work with igor to get FFI nb aligned - for Pharo for the enterprise: I started with Olivier Auverlot but I feel alone :) we should have the DBXtalk chapter! Thanks guile! Stef On Feb 21, 2012, at 6:51 PM, Esteban Lorenzano wrote: > Hi, > > while I see many of your points, I disagree with some of them: > > We have a tool that allow us to deliver complete and powerful applications in 2-6 weeks (and even less): Pharo. > > Right now my small company (of myself :) ) is finishing (bah, doing some change requests) for an application for managing thousands of accounts and data. Application was made on Glamour+Magritte+MongoTalk+Some persistence and reporting tool made by myself, based on magritte. > Customer is really happy, because now they can obtain reports of any kind instead the shit they have before (made in Delphi, but there is not a problem of delphi itself but the programmer using it) > The time to develop from scratch this? Four weeks-man. And if we took off all the work I made to make MongoTalk work, reporting and some personal adjusts to glamour, it would be less than three weeks (is important to know, because that work does not need to be repeated...). > (btw, I could do the same for the web, using Seaside) > > Also, we are working (not yet there, but almost), to accomplish several of the issues not completely done for enterprise: > > 1) we have DBXTalk, to RDBMS. Is slow, but that's a problem of FFI that we think it will be solved soon (with Threaded FFI) > 1.1) we also have a growing set of packages for working with NoSQL (Mongo, Riak, Tokio) > 2) we have UI components and powerful frameworks like Glamour, but I agree there is a lot more work needed there > 3) we have ways to talk to outside world (FFI, NB)... but also I agree more work is needed there (for instance, I would like to embed pharo into other applications, not just call libraries from pharo) > 3.1) we also have SOAP support (never tried, not sure it's status) > 4) For remote: we have Ubiquitalk > 5) authentication: not sure what you mean but we have cryptography and work for secure connections is on the way (with Zodiac) > 6) reporting. Ok, not much here... but there is HPDF package and I will release my HPDFReport and CSVReport classes soon (they are very easy classes anyway, don't expect too much :) > > for... bach modules... not sure what are you meaning with that... > > So yes, many of this issues are not really finished or stable (and that's why I see your concerns)... but just think where we were last year. I'm really optimistic about the future. > > What we really, really need is a book: "Pharo for the Enterprise". Something like the JEE specification, explaining how enterprise customers can use Pharo for their business, right now is a bit confusing, I admit that. > > Other concern (but this is a no-point for discussion, I just wanted to say it :P): Java and C# are not easy at all to learn. They are hard and ugly and new programmers spend years learning it (if they ever learn it completely)... also it is uncomfortable for starters (look how much you need to have a simple "hello, world" there). You think preparing an image is hard? give a new programer a maven script and ask him to build an application with that. Or worst, ask him to add a new dependency... > Industry uses those languages and not Smalltalk for many-many reasons... but this is not one of them. > (Also... there is a lot of big industries still developing on COBOL. sadly) > > best, > Esteban > > El 21/02/2012, a las 2:16p.m., Krishsmalltalk escribiÃ³: > >> >> The choice is ours to make and define. >> >> Yes enterprise is boring for those wanting life on the edge: tech or anything alike... I would love to jump over to the other side... >> >> Its like the freedom of being Picasso vs being a commercial artist in a studio. >> >> Enterprise typically will use software that is stable and capable of being easily usable by newbies. It cares less for the edge of technology, which can be achieved by just a minimal subset of the developer community. Yes no new larger enterprise stuff will happen in COBOL or ilk... But java and c# have proven to be easier to train in freshers, capable of adapting and calling any of the new technology if required etc. The very facts we tout as major winners in smalltalk is actually dimly viewed by the bulk of managers in enterprise: dynamic typing to begin with. They love the fact that the junior dev cannot commit many blunders that smalltalk can carry. Image based runtime, packaging , source code mgmt in st, etc are amongst stuff few comprehend well. Also we lack any decent libraries to for many a task, including reporting, DBMS , soap and many other stuff which when required only the ingenous smalltalker can cobble it, not our general developer base. >> >> I can be specific with tons of example, that we need to push a clean rock stable kernel and winning platform like rails, that make it hugely possible for a small firm to push out completed apps in 2 to 6 weeks. It's like the construction industry, be able to pick all components of the software: authentication, DBMS / ORM , reporting, UI components, messaging, interfaces to outside world viz soap, FFI , Remote , batch modules, ... One can push in a long list... >> >> All this is important only if we want to succeed statistically and that enriches the community to then indulge even more in research, it's symbiotic in that way. The more success you get in the industry the more funding there will be to do fundamental research eventually, the more happier all levels of smalltalkers from the expert to the beginners will be. >> >> Modified Quote from Kung Fu panda: master oogway "enterprise .. No enterprise .. Who cares", what we do care for is the eventual adoption of smalltalk as an equal partner in the landscape of languages, platforms in the world, gives enough money for everyone around. Unequal if it must eventually.. >> >> >> >> On Feb 21, 2012, at 1:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> >>> On Feb 21, 2012, at 3:11 AM, Krishsmalltalk wrote: >>> >>>> Yes, >>>> >>>> Do not emphasize on one or few keywords. Malleable is better than plastic (can be off putting for any environment conscious) >>>> >>>> Adopt the Pharo motto: >>>> >>>> "Pharo shall be one of the best enterprise platform in 3 years." >>> >>> >>> Isn't "Enterprise Plattform" another word for "boring and complicated" ?? >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://marcusdenker.de >>> >>> >> > >

Feb. 21, 2012

Re: [Pharo-project] Why do we use Pharo? a.k.a. rethinking Pharo marketing

by StÃ©phane Ducasse

We could get luffy as a symbol :) Stef (ok ok I should to read the manga of my boys but one piece is fun). > > Oh, hey! How about "elastic"? That one already has a bit of buzz > around it, as in Amazon's "Elastic Compute Cloud" (EC2). > > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > >

Feb. 21, 2012

Re: [Pharo-project] Netstyle experience (was Do not feed the trolls)

by StÃ©phane Ducasse

On Feb 21, 2012, at 3:34 PM, Dave Mason wrote: > > On Feb 21, 2012, at 07:07, Janko MivÅ¡ek wrote: > >> - more stability, > > This is the biggest thing for me. I'm trying to get my Analysis of Algorithms students to recognise and value a powerful environment like Pharo Smalltalk, but some of them are experiencing so many crashes that they've taken to entering their code in Notepad and then pasting it into Pharo!!! This is not a strong advert for Smalltalk or Pharo. I have may be a crash per month or so at the maximum and even in this case I'm doing something nasty. and nobody in our team experience that. Pharo is crashing less than my mac email client! You should report that as soon as you get it. > I suspect many of these crashes are stack overflows. I *thought* that Squeak/Pharo was supposed to recognise stack overflow, but I just wrote a method: > crash > ^self crash + 4 > and my image grew to 500+MB and then crashed. This is with Pharo 1.3 one-click. With 1.1 one-click, I *do* get the Low space window popping up at 516MB (although I don't appear able to do much... it doesn't even seem to quit-no-save); I eventually did a force-quit. This is all on Mac OS X 10.6.8. really? > The 1.3 says: > VM: Mac OS - intel - 1068 - Croquet Closure Cog VM > [CoInterpreter VMMaker-oscog- IgorStasenko.123] 21.0 > Image: Pharo1.3 [Latest update: #13307] > > How can I get more stability? Is it time to move to 1.4? Is there something I or my students can do to help? This is really strange. > > Thanks for everybody's efforts! > > ../Dave

Feb. 21, 2012

[Pharo-project] Fwd: [Pharo-users] pharo & arduino

by StÃ©phane Ducasse

since this will interest some of you :) Begin forwarded message: > From: Ricardo Moran <richi.moran(a)gmail.com> > Subject: Re: [Pharo-users] pharo & arduino > Date: February 21, 2012 6:33:28 PM GMT+01:00 > To: GÃ©rard Duteil <linedubeth(a)free.fr> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > On Mon, Feb 20, 2012 at 8:28 PM, GÃ©rard Duteil <linedubeth(a)free.fr> wrote: > Bonsoir Ã tous, > > Je ne savais que l'on pouvais faire tourner les physical etoys dans pharo, j'utilisais Squeak > > > Plus gÃ©nÃ©ralement je cherche des liens sur les pic, les microcontroleurs et une interface graphique en glisser deposer qui me permette de dialoguer avec de l'Ã©lectronique sous linux. Sous win j'ai des outils mais je prefere l'utilisation de gnu/linux > > je suis tombÃ© sur un lien ancien smalltalk/pic mais j'aimerais bien trouver un projet plus rÃ©cent et maintenu. > > Je vais donc essayer le lien merci > > et je viens de retomber sur le lien qui m'a fait redÃ©couvrir les etoys > > Merci > Au plaisir de vous lire > > Hello, > > Hi GÃ©rard, > > I don't know that physical etoys runs in pharo. I use Squeak and install pe in ubuntu. > > Well, the "Etoys" part of Physical Etoys doesn't run on Pharo, but all the core classes should work fine. I don't know exactly what you need so let me tell you what we did: > We made a very simple model that lets you communicate with your Arduino using a firmware like Firmata, or a simple firmware made by us (see the class comment of the class Arduino for code examples). We also made a very rudimentary C code generator to translate Smalltalk into C and we linked it to the avr-gcc/avrdude so now we can program the Arduino board without leaving Smalltalk, which is very cool. Unfortunately, the translator is still very limited (I think even more limited than Slang) but we are using it to translate the etoys scripts and it's good enough for our purposes. > > > I search more links about pic, electronics and gui with drag and drop to program this electronic's component for kids. I prefer use gnu/linux. > > If you're interested in a graphical interface for kids maybe you'll be better working with the Physical Etoys version instead of using the sources with Pharo. FWIW, making a graphical interface shouldn't be difficult at all but the Etoys interface is being used with kids and it's quite good IMHO. > > > But i don't know your project i use your link > sorry http://tecnodacta.com.ar/gira/projects/physical-etoys/ is my last tool > > > You'll find there the latest version of Physical Etoys, we are soon to release a new version with a lot of improvements. So stay tuned! :) > > > tanks too much for your proposition. sorry i don't speak spanish language but if necessary i transfert your message. > > > I have found a commercial tool s4a. Do you know this? > > Yes, in fact I had the luck to meet its creators in person during the ESUG 2010 conference. S4A is a great tool, and the Scratch interface is very nice. You should definitely give it atry. > > > i have download this http://seaside.citilab.eu/S4ADev.zip > > but i'm a beginner. > > i'm interresting by pharo because it's le lastest program developping, isn'it? > > I'm not sure what that means. We usually don't use Pharo to develop Physical Etoys because, you know, Etoys doesn't run in Pharo. However, I would like to ensure at least some of our project works in Pharo. If I can, I'll test it this week and maybe I'll write a ConfigurationOfArduino. Would that help? > > Cheers, > Richo > > > > thanks a lot > > > > > Le 20/02/2012 09:16, StÃ©phane Ducasse a Ã©crit : > thanks for you answer > I hope that you are going well. > > Stef > > On Feb 20, 2012, at 12:15 AM, Ricardo Moran wrote: > > Hi Stef, > > You can look at the Arduino repository at squeaksource (http://www.squeaksource.com/Arduino.html) > Everything but the "Arduino-Etoys*" packages should work fine in Pharo. At least they worked the last time I checked but a lot has changed since then, so let me know if you encounter any problem, I'll be happy to help. > > Cheers, > Richo > > On Sat, Feb 18, 2012 at 6:15 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > Hi ricardo > > do you have some information how to connect pharo to arduino? > Thanks in advance. > > Stef > > Begin forwarded message: > > From: GÃ©rard Duteil<linedubeth(a)free.fr> > Subject: [Pharo-users] pharo& arduino > > Date: February 18, 2012 9:42:02 AM GMT+01:00 > To: pharo-users(a)lists.gforge.inria.fr > Reply-To: A friendly place where any question about pharo is welcome<pharo-users(a)lists.gforge.inria.fr> > > Hello,,,I search info about this subject., > ,I'm interesting by picaxe also,,,, > A beginner in object programmation,,, > I wait the 25th may,,, > Thanks in advance. > > > > > >

Feb. 21, 2012

Re: [Pharo-project] Netstyle experience (was Do not feed the trolls)

by StÃ©phane Ducasse

Hi janko > More polishing and boring bug hunting tasks therefore and just a bit > less fundamental rewritings like compiler etc. Did you ever look at one bug entry? You see the bug entry does not magically empty itself. There are people like me and marcus and a couple of others that are looking at reports, producing fixes... > Later are more academic and more interesting, yes, but IMHO for us the "enterprise" users the > above priorities are much more important. Well this is not true: - if you want to build the next generation of code coverage tools - better tools - without a good compiler we can also say bye bye to the next generation of optimization do not think that Cog is the end of the story. It is just the start. then you need to be able to understand the code and be able to fix it. So the compiler is important. Stef

Feb. 21, 2012