June 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Saving Seaside components to Monticello

by phil＠highoctane.be

Le 4 juin 2014 21:17, "spearson" <sam(a)xofz.com> a Ã©crit : > > Hello, > I created a Monticello repository on Smalltalkhub. When I commit my > package, my Object subclasses all get saved to the repository. However, > only my WAComponent subclass class definition gets saved (instance/class > variables). The renderContentOn: and updateRoot: methods are not getting > saved to the repository. Is this because they are overridden methods and > not new methods? > > How can I save my renderContentOn: and updateRoot: methods to the > repository? > > Strange. Never had this issue with Seaside. Phil > > -- > View this message in context: http://forum.world.st/Saving-Seaside-components-to-Monticello-tp4761679.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 4, 2014

Saving Seaside components to Monticello

by spearson

Hello, I created a Monticello repository on Smalltalkhub. When I commit my package, my Object subclasses all get saved to the repository. However, only my WAComponent subclass class definition gets saved (instance/class variables). The renderContentOn: and updateRoot: methods are not getting saved to the repository. Is this because they are overridden methods and not new methods? How can I save my renderContentOn: and updateRoot: methods to the repository? -- View this message in context: http://forum.world.st/Saving-Seaside-components-to-Monticello-tp4761679.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 4, 2014

Re: [Pharo-users] HTML5 Generation

by Robert Shiplett

Because I use MIT Curl as markup instead of HTML, this has also been an interest of mine. ( Curl declarative and PL as in www.curl.com and not cURL ) On 4 June 2014 08:59, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > stepharo wrote > > Now it would be really nice to have the seaside canvas as a separate > > component > > After working a bunch with Amber, I really wanted to extract HTML tags in > general, since it's a well-known domain independent of any particular > framework, and then each framework could add its own rendering behavior. As > it is, each framework uses its own proprietary base class for tags, so > things like the cool Seaside Bootstrap wrapper have to be re-implemented > for > each framework. This could be so much simpler and magnify our efforts!! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/HTML5-Generation-tp4761273p4761605.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 4, 2014

Re: [Pharo-users] Form editor

by Hilaire Fernandes

To be ready to catch up on Athens when it will be default rendering engine, you may want have source icon as svg and exported as png with Inkscape. I use this set up for iStoa clipart, oversampled as bitmap for a Nexus 5 screen display resolution, then downscaled at load time to the used display resolution. Hilaire Le 04/06/2014 14:07, Stephan Eggermont a Ã©crit : > Hi Phil, > > I mostly just use Gimp, but that is not a very efficient and effective solution. > Most icons, especially those in flat styles, should be rendered/generated > from a vector format instead of from a bitmap. They should be programmed, > to be themable. Fontographer is actually a much better tool for the kind > of icons found in bootstrap like styles > > Stephan > -- Dr. Geo http://drgeo.eu

June 4, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Sean P. DeNigris

aglynn42 wrote > ...then remember 20000 arcane > commands just to get a project built, never mind debug it +1. Regardless of total size, uniformity is a huge win. There is simplicity in eliminating the context switching from writing code in a language, to configuring the build system in its own (maybe equally complex) language, then learning gdb or whatever... That they ultimately do the same thing if you consider the complex syntax of one along side the entire library of the other is a Turing tar pit argument. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xcode-s-Swift-Playground-tp4761425p4761611.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 4, 2014

Re: [Pharo-users] Form editor

by Stephan Eggermont

Hi Phil, I mostly just use Gimp, but that is not a very efficient and effective solution. Most icons, especially those in flat styles, should be rendered/generated from a vector format instead of from a bitmap. They should be programmed, to be themable. Fontographer is actually a much better tool for the kind of icons found in bootstrap like styles Stephan

June 4, 2014

Re: [Pharo-users] HTML5 Generation

by Sean P. DeNigris

stepharo wrote > Now it would be really nice to have the seaside canvas as a separate > component After working a bunch with Amber, I really wanted to extract HTML tags in general, since it's a well-known domain independent of any particular framework, and then each framework could add its own rendering behavior. As it is, each framework uses its own proprietary base class for tags, so things like the cool Seaside Bootstrap wrapper have to be re-implemented for each framework. This could be so much simpler and magnify our efforts!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/HTML5-Generation-tp4761273p4761605.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 4, 2014

Form editor

by phil＠highoctane.be

Hello, Is there any Form editor (bitmap form) that one could use in Pharo? Example of use would be to edit forms that are making up the icons. e.g. UIThemeWatery>>checkboxSelectedForm Exporting icons and importing them back is quite time consuming. How are you guys dealing with that? TIA Phil

June 4, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Henrik Johansen

On 03 Jun 2014, at 6:32 , Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>>> To what I understand, types are inferred, it is not statically typed. Am I wrong ? >>> >>> If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) >> >> To repeat myself: this is not the case. Example is the RoelTyper. > > Yes, there are many type inferencers for dynamically-typed languages. > But that's not because one builds a type inferencer for say Smalltalk that I can say "Smalltalk has type inference": the inferencer is not integrated within the language, it's just an analysis tool on top. > If someone says that his language has type inference, he means that the type inferencer is built into the language, and normally there is some type checking and/or the compiler is designed to leverage type information which means that the language is at least partially statically-typed (if not entirely). > Because if a language does no type checking nor type-based optimisations, for what purpose would it have type inference built into it? Inferred types have an often overlooked purpose that, IMHO, in dynamic languages, is their biggest benefit. That being, it can reduce the number of false positives in common development actions such as auto-complete, searching for implementors, etc. A pharo with built-in type inference would be no better. A pharo with built-in type inference, and tools utilizing it, would. Itâs a bit of a shame that programmer productivity is a less favourable research area than optimization, when in that case, using the much cheaper type info from PICâs instead, yield equivalent results. (ref. http://www.cs.ucsb.edu/~urs/oocsb/papers/oopsla95-tf.pdf) Cheers, Henry

June 4, 2014

Re: [Pharo-users] Xcode's Swift Playground

by stepharo

Nicolas Passerini and Pablo Tesone are working on a type inferencer for Pharo and this is exciting :) On 3/6/14 17:59, Johan Fabry wrote: > On Jun 3, 2014, at 4:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> We have to do some type inference (for tools) some time. Should be fun. (by the way, is there something like that already?) > There has been some work done on type inference for Smalltalk, the RoelTyper example that I keep mentioning worked on Squeak and there was a version on VW that Roel and I looked at in Gent a couple of years ago, but we did not go that way. More recently there was a google summer of code project on concrete type inference for Pharo if I am not mistaken. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

June 4, 2014

Re: [Pharo-users] Accessing DLLs in Smalltalk/V

by Markus Fritsche

On 30.05.2014 08:50, Joachim Geidel wrote: > Yes, this page helped, but as you wrote: basic and simple example - > the more involved stuff remains undocumented. When working on JNIPort, > I struggled with simple things like de-referencing a pointer to a > pointer to a struct etc. - I didnât find documentation for this, and > this is a basic feature in my opinion. Looking through blog posts and the mailing list archive, I didn't find it so hard to work with (yet), but I am also just dealing with opaque types. One thing I'd wish to learn more about is proper resource management - the library I am using is constructing a tree of connected structs, and I haven't found a recipe how to deal with that (integrating with the pharo vm garbage collector). <thread_hijack>Silly question: where can I find information about finalization et al in Pharo/ Squeak? My google searches didn't yield any results that where easy to understand.</thread_hijack>

June 3, 2014

MorphTree behavior changed

by Hilaire Fernandes

Hi, why when morph tree send updateList there is an announcement from the model? It was not the case before. Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 12:32 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>>> To what I understand, types are inferred, it is not statically typed. Am I wrong ? >>> >>> If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) >> >> To repeat myself: this is not the case. Example is the RoelTyper. > > Yes, there are many type inferencers for dynamically-typed languages. > But that's not because one builds a type inferencer for say Smalltalk that I can say "Smalltalk has type inference": the inferencer is not integrated within the language, it's just an analysis tool on top. > If someone says that his language has type inference, he means that the type inferencer is built into the language, and normally there is some type checking and/or the compiler is designed to leverage type information which means that the language is at least partially statically-typed (if not entirely). I tend to disagree: in the case of Smalltalk the border between the language and the toolchain is quite blurry. Is the browser part of the language? Refactoring support? Type inferencer? Where do you draw the line? I can have my Smalltalk dialect with type inferencing while the language is dynamically typed. And that does not take into account all the fancy type stuff such as gradual typing, like in Gradualtalk, optional typing like Pegon (if Iâm not mistaken). > Because if a language does no type checking nor type-based optimisations, for what purpose would it have type inference built into it? Documentation. Static types are a good form of documentation, when done right. :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Camille Teruel

On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >>> To what I understand, types are inferred, it is not statically typed. Am I wrong ? >> >> If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) > > To repeat myself: this is not the case. Example is the RoelTyper. Yes, there are many type inferencers for dynamically-typed languages. But that's not because one builds a type inferencer for say Smalltalk that I can say "Smalltalk has type inference": the inferencer is not integrated within the language, it's just an analysis tool on top. If someone says that his language has type inference, he means that the type inferencer is built into the language, and normally there is some type checking and/or the compiler is designed to leverage type information which means that the language is at least partially statically-typed (if not entirely). Because if a language does no type checking nor type-based optimisations, for what purpose would it have type inference built into it? > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

June 3, 2014

Re: [Pharo-users] PIllar >> #visitAnnotatedParagraph:

by Ben Coman

Damien Cassou wrote: > On Sun, Jun 1, 2014 at 6:10 PM, Ben Coman<btc(a)openinworld.com> wrote: >> Yes. I am doing something similar. btw, is it a strong convention that Tex commands and environments are all lowercase? That is, should I force the annotation label in "\begin{note}" to lowercase, or should I pass that through unchanged. > > > I think you should not change anything. Is it up to the writer to do > something not stupid. > >>> For Markdown, we should probably have the same solution as for HTML. >> I had a hunt around and it seems that Markdown doesn't support paragraph styles. And the workaround specified here... >> http://stackoverflow.com/questions/1058933/can-i-define-a-class-name-on-par… >> >> apparently does not work on github... >> https://github.com/github/markup > > in pillar we have both Markdown and GithubMarkdown as export options. > So we can have a solution dedicated to github if required. > > >> But Hey! Check this out... >> https://github.com/github/markup/blob/master/CONTRIBUTING.md >> >> Maybe we could add a Pillar-->HTML processor to Github? > > > There should not be any technical problem to do that. Do you want to > try? I can help if you have problems. > > >> "If your markup is in a language other than Ruby, drop a translator script in lib/github/commands which accepts input on STDIN and returns HTML on STDOUT..." >> https://github.com/github/markup/blob/master/lib/github/markups.rb >> >> >> So it seems that Text and Markdown cannot produce different formatted paragraphs. > > for text it is clear. For Markdown I'm still not sure if it is > possible or not. Maybe a<div class=<annotation>> would work. > > >> In those two cases, I still lean towards putting the annotation label in the output, but I'm happy enough to leave it out. > > > for text I think we should not change the current export. For > Markdown, I leave the decision to you. > > I've uploaded the updates to make annotations more consistent, and added the \dothis LaTeX command being used in the PharoLaserGame tutorial. source annotation test # item 1 @@note anno1 @@dothis anno2 ## item 11 @@note anno3 ## item 12 @@dothis anno4 ## item 13 --to=pillar annotation test # item 1 @@note anno1 @@dothis anno2 # ## item 11 @@note anno3 # ## item 12 @@dothis anno4 # ## item 13 Now this output is not the same and the source. Should I try to fix this the same as I did for comments. --to=html <div class="container"> annotation test <ol><li> item 1 </li></ol> anno1 anno2 <ol><li> <ol><li> item 11 </li></ol> </li></ol> anno3 <ol><li> <ol><li> item 12 </li></ol> </li></ol> anno4 <ol><li> <ol><li> item 13 </li></ol></li></ol> </div> --to=markdown annotation test 1. item 1 ^M ^M anno1^M ^M anno2^M ^M 1. 1. item 11 ^M ^M anno3^M ^M 1. 1. item 12 ^M ^M anno4^M ^M 1. 1. item 13 btw, what are all these non-break-spaces "^M ^M" for? --to=markdown \begin{document}^M^M annotation test \begin{enumerate} \item item 1 \end{enumerate} \begin{note} anno1 \end{note} \dothis{ anno2 }\begin{enumerate} \item \begin{enumerate} \item item 11 \end{enumerate} \end{enumerate} \begin{note} anno3 \end{note} \begin{enumerate} \item \begin{enumerate} \item item 12 \end{enumerate} \end{enumerate} \dothis{ anno4 }\begin{enumerate} \item \begin{enumerate} \item item 13 \end{enumerate} \end{enumerate} ^M^M\end{document}^M --to=text annotation test 1. item 1 anno1 anno2 1. 1. item 11 anno3 1. 1. item 12 anno4 1. 1. item 13 cheers -ben

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 4:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > We have to do some type inference (for tools) some time. Should be fun. (by the way, is there something like that already?) There has been some work done on type inference for Smalltalk, the RoelTyper example that I keep mentioning worked on Squeak and there was a version on VW that Roel and I looked at in Gent a couple of years ago, but we did not go that way. More recently there was a google summer of code project on concrete type inference for Pharo if I am not mistaken. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> To what I understand, types are inferred, it is not statically typed. Am I wrong ? > > If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) To repeat myself: this is not the case. Example is the RoelTyper. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 3:10 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> What's interesting about swift is not only that Apple chose an existing name for their new programming language (interesting for a company that is very careful about their own brand names), but that swift seems to be statically typed, while one of the biggest advantages of Objective-C is that it allows for dynamic typing (to some extent)... > > To what I understand, types are inferred, it is not statically typed. Am I wrong ? Type inference is actually orthogonal to static or dynamic typing. You can have a statically typed language with inferred types, where the programmer needs to put type annotations on places where the type inferrer gets lost, and you can infer types for a dynamically typed language. An example of the latter would be the RoelTyper shown at ESUG a looong time ago ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Curl markup with Pillar

by Damien Cassou

On Tue, Apr 22, 2014 at 3:30 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > The links in there do not seem to work. When linking to smalltalkhub the ~is exchanged by %7E I checked and this is not a bug of Pillar but a bug of github's markdown: https://github.com/github/markup/issues/311 -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 3, 2014

Re: [Pharo-users] Configuration browser and Fuel

by Esteban Lorenzano

Hi, On 03 Jun 2014, at 08:01, phil(a)highoctane.be wrote: > In Pharo 3.0 we do have Fuel in the image. > > Now, there is also Fuel in the ConfigurationBrowser. > > When one wants to work with Fuel, should one update the image with what is in the ConfigurationBrowser? no Esteban > > TIA > Phil

June 3, 2014

Configuration browser and Fuel

by phil＠highoctane.be

In Pharo 3.0 we do have Fuel in the image. Now, there is also Fuel in the ConfigurationBrowser. When one wants to work with Fuel, should one update the image with what is in the ConfigurationBrowser? TIA Phil

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Andrew Glynn

I don't think the claim is that Pharo or any Smalltalk is 'simple', but when someone new to coding has to first learn how to pretend they're using a late 70"s terminal and a crappy text editor, then remember 20000 arcane commands just to get a project built, never mind debug it, the price of entry before starting to code is too high. Coding is stressful enough (unlike most people's tasks, it has to actually work) which helps understand why the average age that coders quit and go into another field is only 30 years old. A high initial curve cuts a very short average productive career that much shorter. I wouldn't worry about swift being as bad as JS. Nothing is. On Jun 3, 2014 4:21 AM, "kilon alios" <kilon.alios(a)gmail.com> wrote: > "What makes Pharo and Smalltalk so cool is this magical simplicity on so > many levels." > > I have a problem with this, I think its not sincere. I know that a Pharo > developers would love to throw on my face the basic syntax of Pharo that > can fit in a single page but the truth is that Pharo because it is > Smalltalk it follows the exact same recipe of the "get the F!@#$% out" > which means it throws everything outside the language in form of libraries > of objects. Pharo is definetly not that simple. Why ? Because coding is not > simple . > > So if it is to be a fair comparison take those 500 pages and > find equivalent features in Pharo and I don't think you will find that they > are that different in terms of complexity. > > And its not as if Swift is revolutionary any more than Smalltalk or Pharo > is revolutionary. All languages copy from each other. > > I will have to agree that Pharo appears simpler than Swift, but I doubt > that it does not miss many features that Swift has. As you said its too > early to say. > > I have not read those 500 pages, personally I dont see what the big deal > is, PBE is 400 pages and barely touches what Pharo really is. I fail for > the time being viewing Swift as a complex language, I just hope does not > end up as ugly as JavaScript. Good ideas that are badly implemented. I > doubt it though. > > PS: I am downloading the Swift manual right now > > > On Tue, Jun 3, 2014 at 12:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >> On 03 Jun 2014, at 10:53, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> > For anyone who has not not watched it yet, you can watch the Playground >> demo here. Looks like they were inspired by Bred Victor demos. >> > >> > https://www.youtube.com/watch?v=l62x8Oq_QP4 >> > >> > Swift is statically typed with type inference. BUT it has generics and >> optional types. So it looks like it tries to let you have the cake and eat >> it too. >> >> It is way to early to have an opinion (especially since one should use a >> language before commenting), but ... >> >> 1 - it is very nice to see Apple play in the language design world (it >> will get traction I am sure) >> 2 - it feels like a pretty complex language, both in terms of syntax >> options, concepts and rules, especially around types (the language book is >> 500 pages I believe) >> >> What makes Pharo and Smalltalk so cool is this magical simplicity on so >> many levels. >> >> > It also removes the need for header files , so it really moves away >> from the C paradigm. >> > >> > There is a quick toor here >> > >> > >> https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conc… >> > >> > >> > On Tue, Jun 3, 2014 at 11:29 AM, stepharo <stepharo(a)free.fr> wrote: >> > >> > Hi, >> > >> > The work on GToolkit goes in this direction. Funny enough, we also have >> a Playground :). >> > >> > Look here for an example: >> > >> http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… >> > >> > More will come in this direction. I happen to believe that this is the >> area with the largest potential in Pharo, and it would be great to put more >> effort around it. If people have an interest to participate, please just >> let me know. >> > >> > + 1 >> > >> > Now my plate is full but I encourage people to join effort. >> > >> > Stef >> > >> > >> >> >> >

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by kilon alios

"What makes Pharo and Smalltalk so cool is this magical simplicity on so many levels." I have a problem with this, I think its not sincere. I know that a Pharo developers would love to throw on my face the basic syntax of Pharo that can fit in a single page but the truth is that Pharo because it is Smalltalk it follows the exact same recipe of the "get the F!@#$% out" which means it throws everything outside the language in form of libraries of objects. Pharo is definetly not that simple. Why ? Because coding is not simple . So if it is to be a fair comparison take those 500 pages and find equivalent features in Pharo and I don't think you will find that they are that different in terms of complexity. And its not as if Swift is revolutionary any more than Smalltalk or Pharo is revolutionary. All languages copy from each other. I will have to agree that Pharo appears simpler than Swift, but I doubt that it does not miss many features that Swift has. As you said its too early to say. I have not read those 500 pages, personally I dont see what the big deal is, PBE is 400 pages and barely touches what Pharo really is. I fail for the time being viewing Swift as a complex language, I just hope does not end up as ugly as JavaScript. Good ideas that are badly implemented. I doubt it though. PS: I am downloading the Swift manual right now On Tue, Jun 3, 2014 at 12:00 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 03 Jun 2014, at 10:53, kilon alios <kilon.alios(a)gmail.com> wrote: > > > For anyone who has not not watched it yet, you can watch the Playground > demo here. Looks like they were inspired by Bred Victor demos. > > > > https://www.youtube.com/watch?v=l62x8Oq_QP4 > > > > Swift is statically typed with type inference. BUT it has generics and > optional types. So it looks like it tries to let you have the cake and eat > it too. > > It is way to early to have an opinion (especially since one should use a > language before commenting), but ... > > 1 - it is very nice to see Apple play in the language design world (it > will get traction I am sure) > 2 - it feels like a pretty complex language, both in terms of syntax > options, concepts and rules, especially around types (the language book is > 500 pages I believe) > > What makes Pharo and Smalltalk so cool is this magical simplicity on so > many levels. > > > It also removes the need for header files , so it really moves away from > the C paradigm. > > > > There is a quick toor here > > > > > https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conc… > > > > > > On Tue, Jun 3, 2014 at 11:29 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Hi, > > > > The work on GToolkit goes in this direction. Funny enough, we also have > a Playground :). > > > > Look here for an example: > > > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > > > > More will come in this direction. I happen to believe that this is the > area with the largest potential in Pharo, and it would be great to put more > effort around it. If people have an interest to participate, please just > let me know. > > > > + 1 > > > > Now my plate is full but I encourage people to join effort. > > > > Stef > > > > > > >

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Sven Van Caekenberghe

On 03 Jun 2014, at 10:53, kilon alios <kilon.alios(a)gmail.com> wrote: > For anyone who has not not watched it yet, you can watch the Playground demo here. Looks like they were inspired by Bred Victor demos. > > https://www.youtube.com/watch?v=l62x8Oq_QP4 > > Swift is statically typed with type inference. BUT it has generics and optional types. So it looks like it tries to let you have the cake and eat it too. It is way to early to have an opinion (especially since one should use a language before commenting), but ... 1 - it is very nice to see Apple play in the language design world (it will get traction I am sure) 2 - it feels like a pretty complex language, both in terms of syntax options, concepts and rules, especially around types (the language book is 500 pages I believe) What makes Pharo and Smalltalk so cool is this magical simplicity on so many levels. > It also removes the need for header files , so it really moves away from the C paradigm. > > There is a quick toor here > > https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conc… > > > On Tue, Jun 3, 2014 at 11:29 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi, > > The work on GToolkit goes in this direction. Funny enough, we also have a Playground :). > > Look here for an example: > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > > More will come in this direction. I happen to believe that this is the area with the largest potential in Pharo, and it would be great to put more effort around it. If people have an interest to participate, please just let me know. > > + 1 > > Now my plate is full but I encourage people to join effort. > > Stef > >

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Yuriy Tymchuk

On 03 Jun 2014, at 14:23, kilon alios <kilon.alios(a)gmail.com> wrote: > For anyone who has not not watched it yet, you can watch the Playground demo here. Looks like they were inspired by Bred Victor demos. > > https://www.youtube.com/watch?v=l62x8Oq_QP4 > > Swift is statically typed with type inference. BUT it has generics and optional types. So it looks like it tries to let you have the cake and eat it too. > > It also removes the need for header files , so it really moves away from the C paradigm. > > There is a quick toor here > > https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conc… We have to do some type inference (for tools) some time. Should be fun. (by the way, is there something like that already?) Uko > > > On Tue, Jun 3, 2014 at 11:29 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi, > > The work on GToolkit goes in this direction. Funny enough, we also have a Playground :). > > Look here for an example: > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > > More will come in this direction. I happen to believe that this is the area with the largest potential in Pharo, and it would be great to put more effort around it. If people have an interest to participate, please just let me know. > > + 1 > > Now my plate is full but I encourage people to join effort. > > Stef > >

June 3, 2014