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

Re: [Pharo-dev] The Future of Programming ~ Bret Victor

by Frank Shearar

On 9 December 2013 11:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 09 Dec 2013, at 12:16, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Brilliant talk guys, it's a must watch for smalltalkers, you'll love it >> https://vimeo.com/71278954 >> >> Anybody here knows Bret? > > Yes, we do ;-) > > He does amazing work, including doing excellent presentations of it. That particular presentation is right up there with Guy Steele's "Growing a Language" talk (http://www.youtube.com/watch?v=_ahvzDzKdB0) Both lectures demonstrate through the presentation technique itself, the point of the talk. frank >> sebastian >> >> o/ > >

Dec. 9, 2013

Re: [Pharo-dev] Smalltalk in a C World

by Marcus Denker

On 09 Dec 2013, at 11:37, Torsten Bergmann <astares(a)gmx.de> wrote: > Kilon wrote: >> dlls alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT >> would have to be able to do that in order to be a viable solution. > > You can be sure it can :) > > Clement wrote: >> How can people even know Smalltalk MT still exist with their website and >> their communication ? > > If you follow the hype and advertising you go to Java - if you search > for something more powerful you search for it and will find Smalltalk. > You search and you find a website that convinces you that Smalltalk it indeed dead. Marcus

Dec. 9, 2013

Re: [Pharo-dev] The Future of Programming ~ Bret Victor

by Sven Van Caekenberghe

On 09 Dec 2013, at 12:16, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > Brilliant talk guys, it's a must watch for smalltalkers, you'll love it > https://vimeo.com/71278954 > > Anybody here knows Bret? Yes, we do ;-) He does amazing work, including doing excellent presentations of it. > sebastian > > o/

Dec. 9, 2013

The Future of Programming ~ Bret Victor

by Sebastian Sastre

Brilliant talk guys, it's a must watch for smalltalkers, you'll love it https://vimeo.com/71278954 Anybody here knows Bret? sebastian o/

Dec. 9, 2013

Is it possible to turn a smalltalkhub repo into a Slice ?

by kilon alios

I was wondering if its possible to turn a smalltalkhub repo into a Slice. For example I have created this repo http://www.smalltalkhub.com/#!/~kilon/copyMethod/ for implementing copy and pasting a method as a menu entry in Nautilus. When the code works fine, I will need to submit as slice to fogbuz as a feature enhancement. How I do that ? Is it ok to just sumbit a link to my repo instead ?

Dec. 9, 2013

Re: [Pharo-dev] Json case: Mapping objects to dictionaries

by Norbert Hartl

Paul, Am 05.12.2013 um 19:10 schrieb Paul DeBruicker <pdebruic(a)gmail.com>: > FWIW - The ElasitcSearch stuff only maps to Dictionaries because of an > oversight on my part. It should be fine if those objects materialized as > JsonObjects. What are you doing to get Dictionaries? Its been a while > since I looked at the code. > My question does not rely on exact wording. As JsonObject is derived from Dictionary you can exchange the words Dictionary/JsonObject in my question. Iâm really on to finding a good way going from/to JsonObject/Dictionary. I can do it myself like you do. But if it comes to tasks I know I need more often I like to have something more generalized. Simple approaches have mostly just support for simple conversions but do not support structure changing conversion. Norbert > To map domain objects I usually do something custom because I usually don't > want all inst vars being sent as JSON. An example of what I normally do is: > > #jsonWriteOn: aStream > | y | > > y := JsonObject new. > self varNamesToSerializeAsJson. > do: [ :each | > (self perform: each asSymbol) isNil > ifFalse: [ y at: each put: (self perform: each asSymbol) ] ]. > y jsonWriteOn: aStream > > > and then when materializing: > > > fromJson: aJsonResult > self varsToMaterializeFromJson > do: [ :eachSymbol | > | jsonObj class obj | > jsonObj := aJsonResult at: eachSymbol asString ifAbsent: [ nil ]. > jsonObj notNil > ifTrue: [ > class := MyDomain classForJsonVariableNamed: eachSymbol. > obj := class isNil > ifTrue: [ jsonObj trimBoth ] > ifFalse: [ class fromJson: jsonObj ]. > self perform: (eachSymbol , ':') asSymbol with: obj ] ] > > > > #classForJsonVariableNamed: just looks up in a dictionary that contains inst > var names as keys and classes as values. > > That all being said I'd be interested to learn a better way to do it. > > Hope this helps > > Paul > > > > Norbert Hartl wrote >> What would be the best software to map my objects to dictionaries? There >> are a lot of packages in pharo that deal with JSON somehow. But it seems >> none does mapping from objects to dictionaries and is standalone. Weâve >> got >> >> - NeoJSON package . Maps objects to strings directly for performance >> reason >> - JSON package. Maps string to JsonObject (subclassed from dictionary) >> - Voyage magritte based mapper: Closest to what I find useful but buried >> inside of Voyage. And Iâm not sure it would be easy to factor out this >> module as a standalone mapper. >> - Seaside javascriptâ¦ : I forgot what it really does. I often shy away >> looking at it because I donât want to suck in all the dependencies. >> >> Iâm asking because for me this is an important asset. If we talk about >> JSON there are three things: Objects, JSON structure (being dictionaries >> and other collections in pharo) and JSON strings. Writing to another >> server or to a file producing JSON strings seems to be enough. But using >> it for another system like MongoDB or ElasticSearch this does not work. >> Here the common interface seems to be dictionaries. With ElasticSearch >> mapping dictionaries to JSON and MongoDB mapping dictionaries to BSON. So >> a good descriptive way to map objects to dictionaries would be a good >> thing to have. >> >> Any thoughts? >> >> Norbert > > > > > > -- > View this message in context: http://forum.world.st/Json-case-Mapping-objects-to-dictionaries-tp4727773p4… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 9, 2013

Re: [Pharo-dev] Smalltalk in a C World

by kilon alios

this is why i said " Theoretically of course its possible , but someone would need to implement this to make it easy to do and currently AFAIK none has.". Please note I was talking about Pharo. Even if you take into account Slang , pharo is not compiling to C, it has actually a completely different ideology to C. C/C++ does what it does because it favors raw performance, Pharo does what it does because its favors ease of use , simplicity and flexibility. So its definitely doable technically but the questions is "do you REALLY want to do this". The sort answer NO with the exceptions depending on the situation. Because you don't want to further complicate your life. On the issue of embedding I think its a good option to have but something I rather avoid. If you want to know why , then read this very well written article for python http://twistedmatrix.com/users/glyph/rant/extendit.html. To sum up extending is just better than embedding because it allow you to put focus on your language of choice and take full advantage of its merits. Blender the 3d app , written in C/C++ , embeds python for its addon architecture. Python makes the addons and also manages the GUI. I can tell you there are clear advantages to have blender as python library instead of embedding python inside blender. It would offer a lot easier customization of blender. But since all developers of Blender are C/C++ developers , embedding seemed like an "obvious" solution to them. Mostly because they saw python as a third class citizent in their app. But with blender addons popping up like mushrooms , python has played such a central role to Blender that now it compromises 12% of the 1 million lines of code , blender's code base. 12% might not seem much but once you figure out that python is generally 2-5 times less verbose than C/C++ it become a huge number. Take also to account the world in general move towards dynamic languages mainly because they make life easier and more manageable. For me its far more important to improve Nativeboost and create high quality documentation for it even before considering embedding pharo. On Mon, Dec 9, 2013 at 12:09 PM, Friedrich Dominicus < frido(a)q-software-solutions.de> wrote: > kilon alios <kilon.alios(a)gmail.com> writes: > > > Sort answer is no , Pharo does not try to replace C/C++. CAD plugins > > are indeed dlls and you will need C/C++ for that. I only Know Free > > Pascal as another language to generate DLLs but even in that case its > > extra work. > > > > So if you look for the most direct solution then Pharo wont cut it and > > probably most other programming languages. > > > > Theoretically of course its possible , but someone would need to > > implement this to make it easy to do and currently AFAIK none has. > > > > Bare in mind that DLLs are strictly a C/C++ invention and definitely > > not how highly dynamic languages like Pharo work so there is no direct > > need for Pharo to do such thing cause it would complicate the > > workflow. > I don't this is entirely true. AFAIKT Except Smalltalk can be used for > generateing DLLs. However they are "compiling" to C AFAIKT. I'm quite > sure that one can use ObjectArts Smalltalk also to generate niche Active > X and I bet also shared libraries. > > Regards > Friedrich > > > >

Dec. 9, 2013

Re: [Pharo-dev] Smalltalk in a C World

by Torsten Bergmann

Kilon wrote: >dllsÂ alone wont be enough , plugins are compiled against a runtime or specific libraries (a Plugin SDK) and Smalltalk MT >would have to be able to do that in order to be a viable solution.Â You can be sure it can :) Clement wrote: >How can people even know Smalltalk MT still exist with their website and >their communication ? If you follow the hype and advertising you go to Java - if you search for something more powerful you search for it and will find Smalltalk. Same for ST/MT - if you need something more specific (like building DLLs, COM components, access DirectX/OpenGL, ... and stay with Smalltalk you may end up at their system. I know several projects using MT, it is also used for games (like Aura - Fate of the Ages). Note that also other Smalltalks are able to build DLLs like Dolphin, ST/X and SmallScript. Bye T.

Dec. 9, 2013

Re: [Pharo-dev] Json case: Mapping objects to dictionaries

by Norbert Hartl

Am 05.12.2013 um 17:03 schrieb Chris Cunningham <cunningham.cb(a)gmail.com>: > I've used the SCouchDB interface - which include mapping object to dictionaries (well, JSONObjects) and mapping back from them. > http://www.squeaksource.com/SCouchDB.html > Of course, it is tied to CouchDB, but shouldn't be to hard to pry the mapping part out (once you find it). > Thanks. Iâll take a look at the code. norbert > > On Thu, Dec 5, 2013 at 7:44 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What would be the best software to map my objects to dictionaries? There are a lot of packages in pharo that deal with JSON somehow. But it seems none does mapping from objects to dictionaries and is standalone. Weâve got > > - NeoJSON package . Maps objects to strings directly for performance reason > - JSON package. Maps string to JsonObject (subclassed from dictionary) > - Voyage magritte based mapper: Closest to what I find useful but buried inside of Voyage. And Iâm not sure it would be easy to factor out this module as a standalone mapper. > - Seaside javascriptâ¦ : I forgot what it really does. I often shy away looking at it because I donât want to suck in all the dependencies. > > Iâm asking because for me this is an important asset. If we talk about JSON there are three things: Objects, JSON structure (being dictionaries and other collections in pharo) and JSON strings. Writing to another server or to a file producing JSON strings seems to be enough. But using it for another system like MongoDB or ElasticSearch this does not work. Here the common interface seems to be dictionaries. With ElasticSearch mapping dictionaries to JSON and MongoDB mapping dictionaries to BSON. So a good descriptive way to map objects to dictionaries would be a good thing to have. > > Any thoughts? > > Norbert >

Dec. 9, 2013

Re: [Pharo-dev] Searchbar in the browser

by Sven Van Caekenberghe

On 09 Dec 2013, at 11:19, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > What I would like, is a setting to remove it. > I usually do not use the packages list, > and once you end up tabbing in the search field, > you can not escape without your mouse, > and this is really grinding my gears :s > > So if I could just disable it, I would appreciate it :) +1 I donât like it that (the clutter) much either. If I search for something, I always Shift-Enter and that works super. For the rest, there are menus and keyboard shortcuts. > Ben > > On 08 Dec 2013, at 19:45, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> >> >> >> On Sun, Dec 8, 2013 at 4:41 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Dec 8, 2013, at 4:33 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> > Hi All, >> > >> > You may have noticed that Nautilus now has a search bar next to the list of packages. I personally find this extremely useful. This is the work of Juraj and he is interested in hearing your feedback. >> > >> > The textfield accepts regular expression. It means that entering âRoassalâ will display all the packages having the word âRoassalâ in it (e.g., RoassalExtra, ConfigurationOfRoassal). If I enter â^Roassalâ, it displays all the packages that begin with âRoassalâ. (e.g., RoassalExtra). >> > >> > Any idea how to make this feature more apparent? Anything else you want to see with the searching in the browser? >> >> I would love to have the search bar searching also based on class name >> Maybe -Point >> could select the package that contains the class Point >> -Point* >> could select the package that contains the classes *Point* >> >> +1. >> I could not get used to spotlight search (may be i am too lazy). But this would definitely help and I remember some earlier browser had it, and I used it so often. But then it was removed and I could never get accustomed to the new ways. >> >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> >

Dec. 9, 2013