October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by StÃ©phane Ducasse

> <rant> > It's part of the Pharo manifesto: "Not backward compatible" > </rant> Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious If I can laugh from them this is that I should be quite strong no? We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. It is not easy but people like marcus, sven, esteban, igor, camillo and many many others are dedicated to that goal. All the rest does not matter :) I'm just sad that other smart people do not understand that we want to create a future to everybody not just a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it and I thank them for that. Stef

Oct. 25, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by StÃ©phane Ducasse

this is what I do for the PharoTopics :) On Oct 24, 2013, at 4:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 23 October 2013 20:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > This is really cool, is that in the image already ? > What about plain HTTP repos ? > > > indeed, what could be simpler than: > > Compiler evaluate: (ZnEasy get: 'http://my.url.with.script.st') > > and you can, of course place it on github, if you need version control, like: > > https://raw.github.com/pharo-project/pharo-vm/master/codegen-scripts/LoadVM… > > > On 23 Oct 2013, at 20:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > philippeback wrote > >> Would be great to have a logout, in order to give images to other people > >> without leaving credentials around. > > > > Done, added to world menu under the individual repo login options > > > > The way the logins work is that a file named .mcconfig is expected in the > > general preferences folder with the format: > > > > [squeaksource] > > user := 'me'. > > password := 'pwd'. > > [squeaksource3] > > user := 'me'. > > password = 'pwd'. > > [smalltalkhub] > > user := 'me'. > > password := 'pwd'. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716686.… > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > Best regards, > Igor Stasenko.

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

> > With respect to Seaside (and its cross-platform-ness), this is probably a good decision, for now. > > But it is fundamentally unfair to call this an arbitrary unimportant change meant to annoy people. On the contrary ! I even think that there are too many methods in TAssertable and the #shouldnt: checks are very confusing and are candidates for removal, IMHO. Too much unnecessary code is not good in the long run. > > Have you ever written a #shouldnt: test ? I have never done so ! > > I took a Seaside image and looked at the senders of #shouldnt: and friends. There are that many from Seaside and I havenât seen any good example that could not be written otherwise. > > My 2c. They are important :) Would be good to make a pass on TAssertable too. I will add a discussion and a big warning in the SUnit Chapter for the next release of the PBE. Because Camillo is right. shouldnt:raise: Error should not be used. Stef

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

tx! On Oct 24, 2013, at 1:55 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > From the comments I think we can agree that it is a better to have a lint rule > instead of breaking things the way it was introduced by the original issue #11876. > > I therefore opened an issue > https://pharo.fogbugz.com/f/cases/11989/shouldnt-raise-Error-from-issue-118… > and uploaded a slice > > SLICE-Issue-11989-shouldntraise-Error-from-issue-11876-is-too-offensive-TorstenBergmann.1 > > to Pharo30Inbox on STHub (http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main) that > removed #validateShouldntException: > > I used a fresh 3.0 image (Pharo3.0 Latest update: #30519) > > Please test so it can be integrated and we can continue to focus on more interesting stuff. > > Thanks > Torsten > > >

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

>>> >> >> yes, people are not willing to change code all the timeâ¦ > > We are willing to change the code where there is a clear benefit. For example it's hard to argue that the new filesystem is an improvement over FileDirectory. We have a partically working Spec based UI for the servers. We would happily change the walkback to a new context API should it fix the bugs in the existing one. However this isn't the case with this change. To sole and only purpose of this change is to break code. This is what annoys me. don't worry we understand :) We are building real applications too for real clients too :) This is a one line change and we will revert it. Stef > > Cheers > Philippe > > >

Oct. 25, 2013

Re: [Pharo-dev] VM for Athens Graphics

by StÃ©phane Ducasse

Igor this is not the point. People do not understand that code can be represented as text :) If I save assembly in XML is it XML or assembly. I think that if you have a dll whose contents does not change then it is ok. Stef

Oct. 25, 2013

Re: [Pharo-dev] VM for Athens Graphics

by StÃ©phane Ducasse

> > Ok I was not aware you were thinking about that. So this is good to have this path in my radar. > > Yes, this is actually what we discussed recently with Esteban about possible alternatives and > low-hanging fruits :) I like these ones :) > >> Concerning ARM: >> - Damien Pollet works on ARM assembler for ASMJit. >> as soon as it working, we can try doing something with it. >> >> But in addition, what i would like to do is to move more towards platform-neutral FFI implementation, >> using low-level assembler DSL which is platform neutral. There's a work started on it >> as part of Mate project, but it is yet far from finished. > > I would love that. > Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly > would make it a no go for iPad and friends. > > I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file" > so that we do not have the "assembly generation" problem? > > that's a big question, whether such idea fits into apple technicians/politicans heads or not. > Do you think we have enough time/resources to waste on implementing such mechanism > only to discover later that Apple says 'over my dead body'? > The point is that generating code, saving it to file, and then loading that file as DLL, > is largely a hack. > You either allowed to run your own generated code or not.. because from security perspective, > the fact that you first stored it into file and then load it back doesn't changes a tiny bit. > From design perspective, it is crutch, which don't really buys anything (why on earth, anyone would want to deal with files > and OS, if he could just run code which already in memory?). >

Oct. 25, 2013

Re: [Pharo-dev] API docs?

by projectVALIS

perfect! this is enough to get me going -- thanks!!! -- View this message in context: http://forum.world.st/API-docs-tp4716945p4717010.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 25, 2013

Re: [Pharo-dev] API docs?

by Torsten Bergmann

projectVALIS wrote: > I'm wondering if there are online API docs like there are for Java (here's a > link <http://docs.oracle.com/javase/7/docs/api/> for all you non-Java > types). I've already got a copy of 'Pharo by Example' and 'A Guide to Work > with Squeak Morph Classes', but neither are what I'm looking for. Also, the > 'swiki' doesn't have a comprehensive list. An up-to-date reference of the > morphs and classes available in a stock Pharo image would be immensely > helpful. Does one exist? Sure - one is available in the PharoOnlineHelp. In a fresh Pharo 2.0 or Pharo 3.0 image just open Tools -> ConfigurationBrowser Then select "PharoOnlineHelp" from the list and install it. After loading there is a panel where you can start the local webserver. If you are on Windows then click on "Browse" afterwards to open the webbrowser, otherwise (Mac, Linux) point your browser to http://localhost:8080 In the toolbar click on "API". A screenshot is available here: http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20121129/a… JavaDoc is "dead" documentation since it is just generated from the classes and easily outdated. The Pharo API docu is served right out of the image and is therefore always up to date. It is based on class and method comments that you also have within the environment. Independent from that I would rather use the Smalltalk browser than this kind of docu - it gives you much more control. Have fun T.

Oct. 25, 2013

Re: [Pharo-dev] Unwind error during termination

by Levente Uzonyi

On Fri, 25 Oct 2013, Nicolas Cellier wrote: > Hard to debug this kind of code :( > This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's > an avatar. > > Still, I do not see how you get the errorSubscriptBound:... > In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... > I never saw this, but if Eliot says so... > > > > ExceptionTests>>testHandlerFromAction > Â Â Â "A test ensuring that nested exceptions work as expected." > > Â Â Â | result | > Â Â Â result := [ > Â Â Â Â Â Â [ > Â Â Â Â Â Â Â Â Â [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] > Â Â Â Â Â Â ] on: Error do: [ :ex | 3 / 0 ] > Â Â Â ] on: ZeroDivide do: [ :ex | 'outer' ]. > Â Â Â self assert: 'outer' equals: result description: 'Incorrect handler'. I had an attempt to fix it, but it's incomplete, and other issues popped up: http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165364.h… Levente > > > > 2013/10/24 Igor Stasenko <siguctua(a)gmail.com> > > ok, it seems i found how to reproduce the situation with following: > > [Â [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ] > > you will get halt, and if you close the debugger , it will throw unwind error. > (while instead it should throw DNU) > > > -- > Best regards, > Igor Stasenko. > > > >

Oct. 25, 2013