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

Re: [Pharo-project] Kind of Spreadsheet component for Seaside?

by Marcus Denker

On Dec 11, 2012, at 4:22 PM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: > What happened to Dabble DB? bought by Twitter in a talent acquisition, killed off. > Is any of their source code open? no. > > On Mon, Dec 10, 2012 at 8:44 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> FDominicus wrote >>> I'm just wondering does anyone have/know about a kind of spreadsheet >>> component/application for Seaside? >>> >>> Any hints are welcome >>> >>> Friedrich >> >> >> There is a JQGrid (http://www.trirand.com/jqgridwiki/doku.php) widget in >> JQueryWidgetBox repo on Squeaksource but that is just handy for displaying >> tabular info. Nothing for entering formulas etc. >> >> >> >> -- >> View this message in context: http://forum.world.st/Kind-of-Spreadsheet-component-for-Seaside-tp4658697p4… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >

Dec. 11, 2012

Re: [Pharo-project] Kind of Spreadsheet component for Seaside?

by Peter H. Meadows

What happened to Dabble DB? Is any of their source code open? On Mon, Dec 10, 2012 at 8:44 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > FDominicus wrote >> I'm just wondering does anyone have/know about a kind of spreadsheet >> component/application for Seaside? >> >> Any hints are welcome >> >> Friedrich > > > There is a JQGrid (http://www.trirand.com/jqgridwiki/doku.php) widget in > JQueryWidgetBox repo on Squeaksource but that is just handy for displaying > tabular info. Nothing for entering formulas etc. > > > > -- > View this message in context: http://forum.world.st/Kind-of-Spreadsheet-component-for-Seaside-tp4658697p4… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by H. Hirzel

Marcus, thank you for the link. May I ask somebody who has watched the video to post a few words of a summary here....(keywords are fine) --Hannes On 12/11/12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The inventor of Ruby on Rails gave a talk about this topic: > > https://www.youtube.com/watch?v=VOFTop3AMZ8 > > > On Dec 11, 2012, at 11:02 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> yeah, but that's a direct path to stagnation, and that's what happened >> with fortran, java and all the languages that have put backward >> compatibility as top priority. >> in other side, .net is not backward compatible and it has success anyway >> so, is not so clear for me. >> >> I still prefer to drop backward compatibility time to time to drop a full >> language each 10 years :) >> >> Esteban >> >> On Dec 11, 2012, at 10:23 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> >> wrote: >> >>> I have to say I am on of those people who love backward compatibility. I >>> actually come from a programming language that did exactly what the quote >>> says. It was not a fun experience. Python 3 broke compatibility with >>> python 2. Most of the libraries did ignore python 3 for quite some time >>> and some still do. Actually if you google for "python 3" the second >>> search result of it is the "python wall of shame" where you will find >>> many of python libraries still stuck to python 2. The reason is that is a >>> lot of work to rewrite parts of library to make it compatible with python >>> 3. And note that python 3 has been around for 5 years. And is most likely >>> it will be another 5 till most major python libraries are finally ported >>> to python 3. >>> >>> http://python3wos.appspot.com/ >>> >>> Usually when I see "tragic fate" , "dead" , "declined" etc mentioned in >>> the same sentence with a programming language I am certain that it will >>> mention some "big flaw" of the language and I am going to facepalm >>> myself. In 99% of all case of "dead" languages it has nothing to do with >>> the language itself and has everything to do with hype and lack of good >>> marketing. >>> >>> I can tell you one thing, AFAIK the decision to brake compatibility with >>> python is still a big reason why one should not use python and is >>> considered one of the big flaw of python. I know that some people are in >>> denial, and I agree that python has been improved but not without paying >>> a big price as the "wall of shame" clearly shows. >>> >>> I can bring you another example, blenderpython, its the well known >>> Blender python api of the well known open source 3d app. Well if you take >>> a look at it you will find two things. a) blender 2.5 has been a rewrite >>> which is a very good thing but that ment sacrificing many useful addons >>> because not only the library changed but also they moved from python 2 to >>> 3 and b) API keeps braking compatibility in almost every single version. >>> The result is an army of addons that are left unmaintained because the >>> author makes something but he is not able to maintain every second month >>> because the developer decided to brake compatibility. Users ask for >>> updates to the addons and usually developers search for another developer >>> to maintain but most of those addons are left for dead. And that is >>> thousands of lines of code gone to waste. Actually very few developers >>> stick to blenderpython for this very reason. >>> >>> So no I have to disagree there, between choosing a better language or a >>> useful library and code that works in long term, I choose the second. I >>> am full on progress but I do find braking compatibility is just the easy >>> , convinient solution that does not quite work well in practice . >>> >>> From: Fernando Olivero <fernando.olivero(a)usi.ch> >>> To: "Pharo-project(a)lists.gforge.inria.fr" >>> <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, 11 December 2012, 10:36 >>> Subject: [Pharo-project] About (backwards) Compatibility >>> >>> Hi, i wanted to share an "old" quote which i find relevant to our >>> community. Just replace FORTRAN's with loads of stuff we had in the >>> bloated images in the past, most of them useful to get were we are right >>> now. >>> >>> "FORTRAN's tragic fate has been its wide acceptance, mentally chaining >>> thousands and thousands of programmers to our past mistakes. I pray daily >>> that more of my fellow-programmers may find the means of freeing >>> themselves from the curse of compatibility." >>> >>> Dijkstra, The Humble Programmer, 1972 >>> >>> >>> >>> >> > >

Dec. 11, 2012

Re: [Pharo-project] Helping the noobs help out - i.e. fixing the debugger

by Igor Stasenko

On 11 December 2012 09:32, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The problem right now is that the debugger infrastructure is far more complicated than > it should be, making is hard to change, fix and improve it. > some things are inherently complex. of course, proper (re)factoring helps.. but not much :) > Marcus > -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] NativeBoost and Pharo Kernel

by Igor Stasenko

On 11 December 2012 09:51, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I would like to ask: should NativeBoost be part of the Pharo Kernel? > Currently there are some minor issues like that AsmJit-Extension package > takes ownership of Integer>>#&, False>>#asBit and so on. This is because 1.4 don't have those methods, while 2.0. has (added by Camillo).. and so, currently , NB can either work on both, by making 2.0 image dirty or work only in 2.0, and fail to work in 1.4 because of "missing" methods. I am not very good in metacello-fu to write a confing, which will select various set of stuff to load depending on image version. So, if someone can help, i would appreciate that. I can move those methods into NB-pharo-1.4 package.. > Will NativeBoost be > more closely integrated with the kernel in the near future? > depends on what you putting into "kernel". if it is "a basic functionality, which is absolutely required to do anything else", then no, it will be never part of a kernel. if it is " a set of functionality, ready to use for most common/daily tasks" , then yes it should be part of such kernel.. > BTW, we need to integrate > http://code.google.com/p/pharo/issues/detail?id=7062 before any update that > will move methods between packages. > > Cheers, > -- Pavel -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Igor Stasenko

what is interesting that people don't realize that they can have 2 versions of same software installed, and use one or another, depending on need. -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] Protecting against stack overflow ?

by Igor Stasenko

i would be happy to have something, which can be expressed as following 'unit test': Smalltalk vm setStackDepthLimit: 100. self should: [ self recurseTimes: 101 ] throw: Exception. Smalltalk vm setStackDepthLimit: 0. "no limit" self shouldNot: [ self recurseTimes: 101 ] throw: Exception. -- Best regards, Igor Stasenko.

Dec. 11, 2012

Re: [Pharo-project] Pharo 2

by Esteban Lorenzano

and then you can help us to find the bugs before going to production :) Esteban On Dec 11, 2012, at 10:30 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > thanks for the clarification , Pharo 2 image here I come :D > > From: Marcus Denker <marcus.denker(a)inria.fr> > To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> > Sent: Tuesday, 11 December 2012, 10:58 > Subject: Re: [Pharo-project] Pharo 2 > > > On Dec 11, 2012, at 9:54 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > >> I was wondering if it really worths working with Pharo 2 yet, in terms of stability and new features. >> > > I think soâ¦ there are some bugs left, but not many real showstoppers. > >> First question is the link in the website the link to the latest Pharo 2 image ? >> > yes. > >> Is Athens included in the Pharo 2 image ? >> > No. NativeBoost is, but Athens not. > >> How much production ready Pharo 2 image really is ? >> > To me it looks quite good, but of course only you can decide that as you might use > other parts of the system then me. > >> Should I move to it or is it still a moving target ? >> > > Not at all. We are in Beta, we just allow bug fixes. > >> What new Pharo 2 image offers ? > > We should make a listâ¦ > > Marcus > >

Dec. 11, 2012

Re: [Pharo-project] who is "dfgs"?

by Esteban Lorenzano

... and please, please, please, use real names, not initials when committing packages! Esteban On Dec 11, 2012, at 11:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I would like to ask who has the initials "dfgs". And I have a question for him/her. The VTermInputDriver initialization methods generate a lot of unimplemented calls because they expect a handler object with protocol that is not defined in the image. Do we need the VTerm classes at all? Can you provide an abstract handler class? Or what about to switch this calls to perform:/perform:with: form. > > Cheers, > -- Pavel > >

Dec. 11, 2012

Re: [Pharo-project] NB squeaksource comits

by Igor Stasenko

On 11 December 2012 11:58, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > > On Dec 11, 2012 4:55 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: >> >> On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> >> wrote: >> > Hi Igor, >> > >> > sorry for bothering you again with this issue but again somebody >> > (squeaksource ;)) removed me from the commiters of the NB project. >> > >> added again :) > Thanks > >> >> > Now I have two proposals, a very small one: removing the asm int3, and >> > decrementing the callback counter in >> > #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash >> > on >> > callback error case. >> > >> no, it should not decrement counter in error case, >> because you are not leaved from callback. >> you should always return from callback, otherwise its call will be >> held on stack. > The I guess that we should be able to continue executing after primitive > fail. On my machine VM crashes if I click proceed. It doesn't crash if I > abort though... But when aborting the counter is not decremented... What > shall we do then? Is there any way to gracefully exit to vm, leaving a > proper state? > The only graceful way is to pass the correct return value, so callback will return to caller. If you have an error there, there's little choice.. either user should manually enter the valid value, or quit :) aborting the process with callback is not a good way too.. because you aborting smalltalk process which handling callback, but it is still there, on stack.. So will it make you happy having callback counter decremented, but in fact having not returned from callback? :) -- Best regards, Igor Stasenko.

Dec. 11, 2012