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