Re: [Pharo-dev] Embeddable/scalable Smalltalk VM needs funding for release (repost/update from squeak-dev)

[S Krish]

Great Work..!!

On Mon, May 15, 2017 at 1:01 PM, Zak Fenton  wrote:

> Hi folks. I posted earlier in squeak-dev about a Smalltalk implementation
> I've been working on. The first post was a bit unwieldy, but there was at
> least some interest so I'm posting an update to vm-dev and pharo-dev.
>
>
> Main strong points are that it's embeddable (like Lua or SQLite) and
> scalable (like Erlang). There are weak points too, of course (e.g. hot loop
> performance will be much worse than Squeak/Pharo at this point).
>
>
> The VM itself is pure C and has no dependencies apart from libc and libm.
> It doesn't require a filesystem (you can pipe VM images through custom
> stream implementations or arrays) and it should run well in tight (~1MB)
> memory situations.
>
>
> The extension system is similar to the Unix system call and virtual
> filesystem APIs, so it's kind-of object oriented but in a very "C" way. All
> extension resources are managed properly (so the system can clean up safely
> and/or warn you if you allocate memory and don't deallocate it, for
> example).
>
>
> Extensions are available for cells (threads/individual VMs), shared memory
> (so different cells can communicate efficiently - but also with memory
> protection and calling features for implementing domain-specific JIT
> compilers), windowing and event handling (based on SDL2) and 2D graphics
> rendering (based on Cairo). There are some higher-level libraries (stylable
> GUI system, tight OS integration, 3D modelling, etc.).
>
>
> It's polished in some ways (there's a test suite, an integrated help
> system, colour shell, etc.), but it needs a lot more refinement in others
> (the current GUI style is terrible, it needs more documentation, there's
> only minimal support for keyboard entry, no networking library, etc.).
>
>
> I'd like to release it (ideally as 100% public domain/CC0), but I don't
> want to do so without some way of funding development. The project promises
> a lot and I want to actually deliver with some ongoing updates and support
> (and being able to pay rent next week would also be a plus), so I'm not
> interested in just dumping it on GitHub and calling it a day.
>
>
> So I'm open to any suggestions as to how to fund this project at least in
> the short term and how it might fit into the wider Squeak/Pharo/Smalltalk
> ecosystems, as well as any technical criticism relating to the
> implementation itself.
>
>
> I've put together a basic website describing the implementation in a bit
> more detail (sorry, no downloads yet): http://a4vm.info/
>
>
> -Zak.
>

Re: [Pharo-dev] Mocketry names again

[S Krish]

result should return: [mock someMessage]





On Wed, Apr 20, 2016 at 1:35 PM, S Krish 
wrote:

> +1.
>
> this is easy and simple for any native / non native english ..
>
> Mocketry is really nice btw..
>
> On Wed, Apr 20, 2016 at 7:45 AM, Denis Kudriashov 
> wrote:
>
>>
>> 2016-04-20 13:59 GMT+02:00 Dennis Schetinin :
>>
>>> Why do we need those sophisticated past-something form after should at
>>> all? Why not simply
>>>
>>> mock should receive someMessage
>>>
>>> ?
>>>
>>
>> Maybe. What others think?
>>
>
>

Re: [Pharo-dev] Mocketry names again

[S Krish]

+1.

this is easy and simple for any native / non native english ..

Mocketry is really nice btw..

On Wed, Apr 20, 2016 at 7:45 AM, Denis Kudriashov 
wrote:

>
> 2016-04-20 13:59 GMT+02:00 Dennis Schetinin :
>
>> Why do we need those sophisticated past-something form after should at
>> all? Why not simply
>>
>> mock should receive someMessage
>>
>> ?
>>
>
> Maybe. What others think?
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[S Krish]

Emotional arguments do not change facts.

Contributions of 1000's from 1970's make all of programming languages what
they are. Acknowledgement of heritage period. Carry on with the great work,
which future generations will acknowledge, even more the contributions of
all around Pharo around today, I am sure.


On Sat, Mar 5, 2016 at 1:40 PM, stepharo  wrote:

> You probably leave in a protected environment but I do not live in the
> same.
> Did you check numPy recently or R? momemtum?
> Do you think that people do not know how to count?
> In 1980 my students were not even born, so how can it be better than
> python, java, c#, lua, ...
>
> Do you think that it makes me happy to see my old friends leaving our
> language and do node.js.
> Seriously.
> Why do you blame me? Frankly tell to leave Pharo and I will leave. I can
> tell you.
> I think that I need a break in my life in this moment so it would be a
> good opportunity.
> Because if each time I do something to improve the wealth and visibility
> of our system
> I get such kind of feedback then may be this is the time to do something.
> Afterall I may be wrong.
> Seriously if you think that I'm not doing a good job and you want to stay
> with old friends
> just let me know. but if I stay then do not tell me that I'm an asshole
> that does not want to
> promote smalltalk.
>
>
> Stef
>
> Le 5/3/16 02:18, Eliot Miranda a écrit :
>
>
>
> On Fri, Mar 4, 2016 at 12:08 PM, stepharo  wrote:
>
>>
>> SciPharo? Not so great news from my POV.
>> What is so much pharo specific in this library?
>> Is Smalltalk scientific community large enough for yet another split?
>>
>> Split of what? Let us be tagged with a name of 1980 and die in peace. Yes
>> this looks like a
>> smart move.
>> There are just Python and R and Javascript around (not talking about ruby
>> and swift)
>> so this is a great move. We are not the cobol of object-oriented
>> programming!!
>>
>
> When I read sentiments like this it makes me want to leave the community.
> I find it so offensive that the Pharo community uses Smalltalk but wants to
> distance itself.  It feels like theft or massive disrespect for the
> inventors of the language, or a complete lack of gratitude.
>
> C is older than Smalltalk and no one says "C is the cobol of low-level
> imperative languages".  List is much older than C but no one wants to
> rename Lisp because it is perceived as old.
>
> Smalltalk is a beautiful name, carefully chosen to differentiate and
> identify the system as different, not arrogant, not hieroglyphic.  Further,
> Smalltalkl /is/ different and distinctive materially.  Why anyone would be
> ashamed of that incredible heritage and pervasive influence is beyond me.
>
> Offended,
> Eliot
>
>
>

Re: [Pharo-dev] Call about Numerical Methods in Pharo :)

[S Krish]

+1

On Sat, Mar 5, 2016 at 6:48 AM, Eliot Miranda 
wrote:

>
>
> On Fri, Mar 4, 2016 at 12:08 PM, stepharo  wrote:
>
>>
>> SciPharo? Not so great news from my POV.
>> What is so much pharo specific in this library?
>> Is Smalltalk scientific community large enough for yet another split?
>>
>> Split of what? Let us be tagged with a name of 1980 and die in peace. Yes
>> this looks like a
>> smart move.
>> There are just Python and R and Javascript around (not talking about ruby
>> and swift)
>> so this is a great move. We are not the cobol of object-oriented
>> programming!!
>>
>
> When I read sentiments like this it makes me want to leave the community.
> I find it so offensive that the Pharo community uses Smalltalk but wants to
> distance itself.  It feels like theft or massive disrespect for the
> inventors of the language, or a complete lack of gratitude.
>
> C is older than Smalltalk and no one says "C is the cobol of low-level
> imperative languages".  List is much older than C but no one wants to
> rename Lisp because it is perceived as old.
>
> Smalltalk is a beautiful name, carefully chosen to differentiate and
> identify the system as different, not arrogant, not hieroglyphic.  Further,
> Smalltalkl /is/ different and distinctive materially.  Why anyone would be
> ashamed of that incredible heritage and pervasive influence is beyond me.
>
> Offended,
> Eliot
>

[Pharo-dev] Java Future

[S Krish]

*Opportunities.. for Pharo..*


*The email, sent to InfoWorld on Tuesday by a former high-ranking Java
official, claimed to feature details from inside Oracle. It said the
company was becoming a cloud company, competing with Salesforce, and “Java
has no interest to them anymore.” The subject line cited “Java – planned
obsolescence.”*

*Oracle is not interested in empowering its competitors and doesn’t want to
share innovation, the email further alleges. The company is slimming down
Java EE (Enterprise Edition), but it also doesn’t want anyone else to work
on Java or Java EE and is sidelining the JCP (Java Community Process).
“They have a winner-take-all mentality and they are not interested in
collaborating,” said the email. “Proprietary product work will be done on
WebLogic, and there’ll be a proprietary microservices platform.” WebLogic
is the Java application server Oracle acquired when it bought BEA Systems
in 2008.*

https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should-y?edition=115055&utm_source=Spotlight&utm_medium=email&utm_campaign=java%202015-11-24

Re: [Pharo-dev] Does anyone remember details of a "pro-Smalltalk" merger circa 2013?

[S Krish]

Surprising from a "follow the herd" psyche amongst the corporate management
and all institutions. They are wary of Smalltalk in general with very few
competent resources available makes them more incapable to drive their
personal agenda. Also for institutions, the insecure nature of Smalltalk,
the lack of standardized monitoring tools et als is another factor that
plays to opt for Java or .Net.

I suspect this maybe an on the cloud, self managed service which is
assessed purely on its merits... if its true.



On Fri, Oct 30, 2015 at 11:53 PM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> I heard an anecdote of a recent merger between two companies in which one
> had
> over 200 people supporting a Java application and the other had ~25 people
> supporting a Smalltalk application. The surprising result was that the
> Smalltalk application was selected for the merged company rather than the
> Java one.
>
> I would like to know which companies were involved, when this occurred, and
> what the precise details were.
>
>
> Thank you!
>
>
>
> --
> View this message in context:
> http://forum.world.st/Does-anyone-remember-details-of-a-pro-Smalltalk-merger-circa-2013-tp4858715.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [ANN] Multiple Desktop support for Pharo 5

[S Krish]

Nice..!.. The shortcuts : Ctrl+D+P .. n others dont work on Windows..

On Thu, Aug 27, 2015 at 6:49 AM, Torsten Bergmann  wrote:

> Julien Delplanque provided this week a goodie to switch between
> "desktops" - but his initial solution was more or less hiding windows
> and not really switching between real Pharo worlds/desktops.
>
> I gave him some tips what could be done on the pharo-user list. Havent
> heard
> from him afterwards.
>
> Now I was able to spend a few hours on this topic myself and implemented
> a full multiple desktop solution myself.
>
> This works in Pharo 5 only (currently) and requires latest VM (at least on
> Windows)
> from files.pharo.org to get the keyboard shortcuts right.
>
> To try:
>
>   Gofer new
> smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager';
> configuration;
> loadDevelopment.
>
> The goodie has some nice features like keyboard navigation, world menu
> integration and even a custom spotter with preview of the desktops.
>
> Quick start:
> ===
>  - evaluate the above expression in a Pharo 5 image
>  - check the world menu "Desktop"
>  - you can press CTRL + D and then CTRL + A (= Desktop Add) to add a new
> desktop
>  - you can press CTRL + D and then CTRL + D (= Desktop Desktop) to open
> the overview
>  - you can press CTRL + D and then CTRL + P (= Desktop Previous) to
> navigate to the previous desktop
>  - you can press CTRL + D and then CTRL + N (= Desktop Next) to navigate
> to the next desktop
>
> The code is hopefully a good example on how to build a custom spotter,
> shortcuts, inspector extensions, ...
> Additionally all this is described in a new article including screenshots
> and a guide on how to use this new goodie:
>
>https://medium.com/@astares/multiple-desktops-for-pharo-5cbc46f3179f
>
> Actually the article took more time to write than coding but I hope
> it helps explaining Pharo and why it is a power tool.
>
> Project is on
> http://www.smalltalkhub.com/#!/~TorstenBergmann/DesktopManager
> Article and code is still subject to change.
>
> Have fun
> T.

[Pharo-dev] Bill Gross: The single biggest reason why startups succeed

[S Krish]

Check out this amazing TEDTalk:

Bill Gross: The single biggest reason why startups succeed
http://on.ted.com/h15YB

Re: [Pharo-dev] OpenAL bindings.

[S Krish]

Is openAL proprietary now.. ? I guess it was open source and there is a
fork now.

On Fri, Jul 10, 2015 at 7:21 AM, Ronie Salgado  wrote:

> Hello,
>
> I made bindings for OpenAL, a 3D audio library.
>
> Here I made a quick demo: https://youtu.be/0wqbJrfYmU8
>
> Next, I will integrate it into Woden.
>
> Greetings,
> Ronie
>

Re: [Pharo-dev] Extending NeoJSON

[S Krish]

You are right. Stick to pure json spec is best as NeoJSON / Gson does.

Anything else should be application's headache, exactly as Gson advices, as
much is yours.


I was just not shaking of the XMLRPC / SOA approach out of my head. It is
getting cleared now. !.. let me work through my use case and come back if I
need to at all on this.



On Fri, Feb 13, 2015 at 7:04 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> I had a more detailed look at json-io and read the code a bit.
>
>
> First, this does not seem to be too popular in the Java world, there is no
> formal spec, I don't see or hear about much uptake. So from that
> perspective, why follow it ?
>
> Second, although at a first look their extensions seem reasonable, most
> are quite Java specific, some inefficient.
>
> The contents of @class is pure Java, it can even include their ugly
> primitive array syntax (like '[B') if I understood it well. How can that be
> universally mapped to another, different language ?
>
> Their handling of primitive/non-primitive types (the endless int/Integer,
> ... mess) makes the code quite complicated and some of that will probably
> come through. We don't have those artificial differences.
>
> Their custom handling of some special classes (Date, Timestamp, Timezone,
> Class, ..) is understandable but again Java specific and not formally
> written in a spec.
>
> There seems to be @items and @keys fields that look suspicious.
>
> Any non-Java language will have trouble being 100% compatible with that
> design. It is probably not impossible to do, but why would you want to do
> that ? You will always be a second rank citizen.
>
> The handling of references using @id and @ref requires that the writer
> makes two passes over the object graph (because it has to know up front
> which objects will be used as reference targets). That is inefficient.
>
> Like I said, STON does all of the above, but a bit better, IMHO, but I am
> biased of course. FUEL, although different by being binary, handles the
> same and more edge cases. When you want to magically serialise *any*
> object, you always hit (language) implementation details, which are not
> good for cross language portability.
>
>
> IMO, json-io was *not* written with the goal of being cross-platform
> (meaning cross-language).
>
> There is a reason why JSON is what it is, limitations and all. It is quite
> restricted, but it gives you portability.
>
>
> All that being said, you could perfectly use Neo-JSON as a building block
> to work with the json-io format, by going through a Maps/Lists
> (Dictionary/Array) intermediate representation. It is a bit less efficient,
> but I will work.
>
> Point>>#asJsonIo
>   ^ { #'@class'->'java.awt.Point'. #x->x. #y->y } asDictionary
>
> Point class>>#fromJsonIo: map
>   ^ self x: (map at: #x) y: (map at: #y)
>
> You will have to maintain a Point to 'java.awt.Point' mapping. And you
> will have to walk the object graph to handles references.
>
> But it will take time to get feature equality and a functioning
> implementation.
>
>
> Sven
>
> > On 12 Feb 2015, at 11:01, S Krish 
> wrote:
> >
> >
> >
> > https://github.com/jdereg/json-io
> >
> > I like the additional features of json-io  : @ref / @id pair
> >
> > If we can have an JSONExtension which plays well with json-io, we have a
> simple way to interact with Java/Scala/Groovy JVM world for default.
> >
> > Present these as literals: String, Numbers, Date, Time, Literal Arrays ,
> booleans
> >
> > Rest all are type based marshalling/ unmarshalling
> >
> > "@type": "fully.qualified.name.toClass"  for Pharo we can ignore the
> package name.. which can be the Category specifier for serialization
> purposes.
> >
> >
> >
> >
> > On Thu, Feb 12, 2015 at 3:05 PM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
> >
> > Even for GSON:
> >
> >
> http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.html
> >
> > {
> >
> > "type": "Circle",
> >  "properties": {
> >
> > though I prefer json-io:  @type to make it unambigous for any case with
> instance variable named type and does not add another node to the tree..
> >
> >
> >
> > On Thu, Feb 12, 2015 at 2:58 PM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
> >
> > I get your point .. like GSON we should not type the json string output,
> if we want it to adhere abs to spec.
> >
> > The saving grace for gson in Ja

Re: [Pharo-dev] Extending NeoJSON

[S Krish]

https://github.com/jdereg/json-io  <https://github.com/jdereg/json-io>

I like the additional features of json-io  : @ref / @id pair

If we can have an JSONExtension which plays well with json-io, we have a
simple way to interact with Java/Scala/Groovy JVM world for default.

Present these as literals: String, Numbers, Date, Time, Literal Arrays ,
booleans

Rest all are type based marshalling/ unmarshalling

"@type": "fully.qualified.name.toClass"  for Pharo we can ignore the
package name.. which can be the Category specifier for serialization
purposes.




On Thu, Feb 12, 2015 at 3:05 PM, S Krish 
wrote:

>
> Even for GSON:
>
>
> http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.html
>
> {
> "type": "Circle", "properties": {
>
> though I prefer json-io:  @type to make it unambigous for any case with
> instance variable named type and does not add another node to the tree..
>
>
>
> On Thu, Feb 12, 2015 at 2:58 PM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
>
>>
>> I get your point .. like GSON we should not type the json string output,
>> if we want it to adhere abs to spec.
>>
>> The saving grace for gson in Java is if you just give the root level
>> object type, rest of it is automatic typing. We lack that capability in
>> Pharo. Though there also for types specified as an interface can then
>> require code assistance in deserializing.
>>
>> So either we follow a meta data route, code helper methods, that is
>> needed for deserializing a JSON as spec or let it have an optional @type
>> tag..  to make the whole thing automatic
>>
>> That way we can be both gson / or any other lib compatible for reading
>> given format ignoring the extra tag, but helps if given to hydrate the
>> object.
>>
>>
>>
>>
>> On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe 
>> wrote:
>>
>>> Hi,
>>>
>>> I will read a bit about json-io and come back to you.
>>>
>>> In any case, JSON is a standard that explicitly excludes typing info,
>>> and yes I know it has been added in several places. NeoJSON's mission is to
>>> stay true to the pure spec and to be efficient. Of course, it could be
>>> extended or subclassed if its original goals remain in place.
>>>
>>> BTW, STON is what I think JSON with typing info should be ;-)
>>>
>>> Sven
>>>
>>> > On 12 Feb 2015, at 06:33, S Krish 
>>> wrote:
>>> >
>>> >
>>> >
>>> > Can I extend NeoJSON to be more like json-io.
>>> >
>>> > * Object serialization
>>> > * format synchronization
>>> >
>>> > To help make it bidirectional for Pharo to external world
>>> serialization / deserialization
>>> >
>>> >
>>> > Seems the closest to what is appropriate for Pharo - Scala/ Groovy /
>>> Java
>>> >
>>> >
>>> > Gson : no type information..
>>> > Jackson: painful annotation or workarounds
>>> >
>>> >
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] Extending NeoJSON

[S Krish]

Even for GSON:

http://www.javacodegeeks.com/2012/04/json-with-gson-and-abstract-classes.html

{
"type": "Circle", "properties": {

though I prefer json-io:  @type to make it unambigous for any case with
instance variable named type and does not add another node to the tree..



On Thu, Feb 12, 2015 at 2:58 PM, S Krish 
wrote:

>
> I get your point .. like GSON we should not type the json string output,
> if we want it to adhere abs to spec.
>
> The saving grace for gson in Java is if you just give the root level
> object type, rest of it is automatic typing. We lack that capability in
> Pharo. Though there also for types specified as an interface can then
> require code assistance in deserializing.
>
> So either we follow a meta data route, code helper methods, that is needed
> for deserializing a JSON as spec or let it have an optional @type tag..  to
> make the whole thing automatic
>
> That way we can be both gson / or any other lib compatible for reading
> given format ignoring the extra tag, but helps if given to hydrate the
> object.
>
>
>
>
> On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe 
> wrote:
>
>> Hi,
>>
>> I will read a bit about json-io and come back to you.
>>
>> In any case, JSON is a standard that explicitly excludes typing info, and
>> yes I know it has been added in several places. NeoJSON's mission is to
>> stay true to the pure spec and to be efficient. Of course, it could be
>> extended or subclassed if its original goals remain in place.
>>
>> BTW, STON is what I think JSON with typing info should be ;-)
>>
>> Sven
>>
>> > On 12 Feb 2015, at 06:33, S Krish 
>> wrote:
>> >
>> >
>> >
>> > Can I extend NeoJSON to be more like json-io.
>> >
>> > * Object serialization
>> > * format synchronization
>> >
>> > To help make it bidirectional for Pharo to external world serialization
>> / deserialization
>> >
>> >
>> > Seems the closest to what is appropriate for Pharo - Scala/ Groovy /
>> Java
>> >
>> >
>> > Gson : no type information..
>> > Jackson: painful annotation or workarounds
>> >
>> >
>>
>>
>>
>

Re: [Pharo-dev] Extending NeoJSON

[S Krish]

I get your point .. like GSON we should not type the json string output, if
we want it to adhere abs to spec.

The saving grace for gson in Java is if you just give the root level object
type, rest of it is automatic typing. We lack that capability in Pharo.
Though there also for types specified as an interface can then require code
assistance in deserializing.

So either we follow a meta data route, code helper methods, that is needed
for deserializing a JSON as spec or let it have an optional @type tag..  to
make the whole thing automatic

That way we can be both gson / or any other lib compatible for reading
given format ignoring the extra tag, but helps if given to hydrate the
object.




On Thu, Feb 12, 2015 at 1:13 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> I will read a bit about json-io and come back to you.
>
> In any case, JSON is a standard that explicitly excludes typing info, and
> yes I know it has been added in several places. NeoJSON's mission is to
> stay true to the pure spec and to be efficient. Of course, it could be
> extended or subclassed if its original goals remain in place.
>
> BTW, STON is what I think JSON with typing info should be ;-)
>
> Sven
>
> > On 12 Feb 2015, at 06:33, S Krish 
> wrote:
> >
> >
> >
> > Can I extend NeoJSON to be more like json-io.
> >
> > * Object serialization
> > * format synchronization
> >
> > To help make it bidirectional for Pharo to external world serialization
> / deserialization
> >
> >
> > Seems the closest to what is appropriate for Pharo - Scala/ Groovy / Java
> >
> >
> > Gson : no type information..
> > Jackson: painful annotation or workarounds
> >
> >
>
>
>

[Pharo-dev] Extending NeoJSON

[S Krish]

Can I extend NeoJSON to be more like json-io.

* Object serialization
* format synchronization

To help make it bidirectional for Pharo to external world serialization /
deserialization


Seems the closest to what is appropriate for Pharo - Scala/ Groovy / Java


Gson : no type information..
Jackson: painful annotation or workarounds

Re: [Pharo-dev] Some debugger vars incorrectly displayed as nil

[S Krish]

+1

I am seeing it repeatedly in my looped / recursive calls a lot ..

On Mon, Feb 9, 2015 at 10:12 PM, Ben Coman  wrote:

> I've seen it.  I was trying to characterise it some more before logging an
> issue myself.
>
> On Tue, Feb 10, 2015 at 12:30 AM, Yuriy Tymchuk 
> wrote:
>
>> Hi,
>>
>> some from time to time some variables are shown in the debugger as nils,
>> despite the fact that they are not (if you inspect them you get a value).
>>
>> Is it a known issue? By the way in “all temp vars” it’s displayed fine,
>> I’ll add screenshots:
>>
>>
>> Uko
>>
>
>

Re: [Pharo-dev] Pharo Seaside and Angular JS

[S Krish]

Updated to Gofer Scripts.. all dependencies self contained including
customJs / customCss...

Instructions updated in the same wordpress link:

https://skrishnamachari.wordpress.com/2015/02/04/angular-js-in-seaside/



On Wed, Feb 4, 2015 at 11:38 AM, S Krish 
wrote:

>
>
> A very initial attempt at getting Angular JS working.. Works out cool..
>
> 

>
> Has simple extension to Teapot to do asynch requests but toying with an
> event push based to make Seaside UI server work with a Teapot REST server
> in Aysnch mode to increase throughput.
>
> Could work with more than 200 requests in 175 ms with asynch calls where
> the synch calls took 5300+ms as calls queue up on the seaside ui server
>
> Can progress this to a scalable / flexible web framework with other
> components viz: logging, nls, mq ?saq2
>
>
>

Re: [Pharo-dev] What Logging framework for Pharo

[S Krish]

Appenders in Log4J describe an end point to send the log data/ event object
to.

So you can have a rolling_file ,   socket TCP connection, MQ , DB table ,
console ... any you  need, many already provided with their custom code to
pipe the info to the end point.

Appenders are now configurable ( in code ) typically in XML to be able to
pipe it to a file in Production / or a DB . While in dev it is to the
console.

You can have the same log sent to multiple Appenders with events filtered
logically for each of them, with one of the Appender getting the whole dump
of events.

The critical issue in logging is performance impact of logging too much.





On Tue, Jan 13, 2015 at 5:46 PM, stepharo  wrote:

>
>  These are nice. There is still value in Log4s with its variery of
>> appenders.
>>
>>
> what is an appender?
>
> And yes soon I will come back to Beacon+SystemLogger+
>
>

Re: [Pharo-dev] What Logging framework for Pharo

[S Krish]

Its a matter of viewpoint here.. while I would agree that the needs
outlined in your note are valid.

Log4J does a good job of what I would consider the laymen spirit of logging
production , UAT ( at client site ) with real data and workflow textual
logs. The default event logging done captures the specific of class, line
number, timestamp, method et als.

* the rendered string that is 90% of the logging use is formatted
string to a file / channel with options of logging the event object to DB /
MQ et als
* the events logged do have a fair amount of information that can be
used for automation tooling around it
* the rendered string too can be usefully queried for much information
* the 7 levels of logging of info, trace, debug, warn, error allows for
optimization in production run to keep it at "warn" and reduce the
performance.
 The purpose is to reduce the number of logging events routed
to an appender, performance is impacted if it goes 10 / 100 times larger..
  While UAT it is typical to work with debug to get more
information of the replicated issue.

The 80-20 rule in typical enterprise is to capture the log trace of the
exception / error and use that to fix a bug, mostly trivial use of the
logging information.
Rarely if ever have I seen the log is used for deep dive analysis for
improving the product, though it certainly can be and is done.

So in log4j it is upto the configuration that allows one to log event
object or formatted strings and to have finer control over amount of log
events channelled and to any number / types of appenders eventually as per
customer convenience.  Given there may be 100's of customers with varied
needs, it is ok to have that flexibility.

I do find log4j as such a very enterprise like framework, which may seem to
posses gaps you point out, but for almost 99% of its usage it fits in very
well.



On Tue, Jan 13, 2015 at 3:24 PM, Tudor Girba  wrote:

> Hi,
>
> Log4j types of logging systems do a reasonable job at capturing log
> entries, but they are poor at helping the human make sense of the produced
> log. Of course, they do attempt, but given that they see the log as a long
> string, there is a significant mechanism built around formatting.
>
> This is broken because it implies that the human should read the log as a
> way of understanding it. This works fine for a couple of lines but fails
> miserably for even Mb logs (not to mention larger logs). One could tweak
> the formatting to make it machine readable, but in practice all logs I have
> seen in enterprise systems are mostly unstructured and one has to spend
> great effort to extract the useful information out of them. For example, I
> use the information in logs to understand performance and diagnose errors,
> and I am using automatic tools for that. But, to build those tools, the
> hardest part is to parse the log. That cost should not exist.
>
> The object as an item of logging preserves the original information so
> that the machine can read it. String is just a way of serializing an
> object, and we should only use it only in this way. Formatting still has a
> place, but it should be clear that it is just one tool - most often the
> least useful one. That is the reason why in Beacon, there is no formatting
> in the core.
>
> Priority is another thing I find rather artificial. For example,
> developers should mark as DEBUG things that are not useful in production,
> but in the end, they mark as DEBUG things that are too large to have in
> production all the time. The problem with this is that sometimes you really
> want to have access to a very specific event regardless of "priority". So,
> a better way of looking at filtering is by allowing the developer to cherry
> pick any event at any given moment.
>
> We definitely have to get good at the backend, but logging objects should
> provide a significant advantage.
>
> Cheers,
> Doru
>
>
>
> On Tue, Jan 13, 2015 at 10:05 AM, S Krish <
> krishnamachari.sudha...@gmail.com> wrote:
>
>>
>> Log4J does do Event object logging by default. I see it may be relevant
>> to roll it into log4s also.  I remember Toothpick probably did that
>>
>> On Tue, Jan 13, 2015 at 11:30 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>> First of all, I am not the developer of Log4s, but I have been using it
>>> for a while and I see no significant gain switching to SystemLogger or
>>> ZnLogEvent. As Alain said, it is based in Log4j, which has his own
>>> Wikipedia page: http://en.wikipedia.org/wiki/Log4j
>>>
>>> I don't think there is too much sense in having "Log Objects" around,
>>> where probably I want to tail a daily rolled log from a hea

Re: [Pharo-dev] What Logging framework for Pharo

[S Krish]

Log4J does do Event object logging by default. I see it may be relevant to
roll it into log4s also.  I remember Toothpick probably did that

On Tue, Jan 13, 2015 at 11:30 AM, Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> First of all, I am not the developer of Log4s, but I have been using it
> for a while and I see no significant gain switching to SystemLogger or
> ZnLogEvent. As Alain said, it is based in Log4j, which has his own
> Wikipedia page: http://en.wikipedia.org/wiki/Log4j
>
> I don't think there is too much sense in having "Log Objects" around,
> where probably I want to tail a daily rolled log from a headless remote
> image. I read the documentation of SystemLogger hoping to find a mechansim
> which dynamically selects compression strategies based in what's logged, or
> some other advanced feature, but I didn't found any :(
>
> So if Object logging is implementing #asLog and #logClass methods maybe I
> should add them so Log4s can log "Object" :). But seriously, such
> comparison is not fair. Let's compare real logging features: priorities,
> levels, appenders, output destinations, hierarchical logging, formatting
> layout, etc. Many of them are implemented in Log4s.
>
> Cheers,
>
> Hernán
>
> 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe :
>
>
>> > On 12 Jan 2015, at 18:27, Alain Rastoul  wrote:
>> >
>> > hi all,
>> >
>> > Googling a bit for a logging framework in Pharo, I found sl4j, which
>> sounds  familiar to me.
>> > http://ss3.gemstone.com/ss/Log4s.html/Wiki
>> >
>> > I suppose the API is the same as the java package, as claimed by the
>> project page.
>> > I wonder if anybody is using it , or has tried it and have an advice on
>> that package ?
>> > (I  saw there was no test and no comments ... :( )
>> >
>> > I think it could be great for Pharo to have a standard package like
>> that, a logging facility is mandatory for most -if not all- applications
>> >
>> > Any advice or pointers ?
>>
>> Object logging instead of String logging is the way to go. SystemLogger,
>> Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past
>> discussions.
>>
>> > TIA
>> > --
>> > Regards,
>> >
>> > Alain
>> >
>> >
>>
>>
>>
>

Re: [Pharo-dev] The Smalltalk Revolution

[S Krish]

Just the year ahead, we will have some framework(s) to push that ahead.
There is quite bit of ground work done as I see through last few years, it
is beginning to be a fertile ground for Pharo to sprout some of the
enterprise frameworks in due time.

On Fri, Jan 9, 2015 at 4:14 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

> It is true that Reddit and HN are the frontier but "battling" is a
> terrible metaphor to embrace.
>
> You don't battle naysayers. Nobody has the money and emotional labor to do
> it. You don't battle them because if you do and you win, you will be "full
> of reason", less productive, with potentially transforming a naysayer in a
> hater and no real gain (no wealth creation in the process).
>
> The alternative is to indirectly prove them wrong by simply showing that
> Smalltalk is more than adequate to implement  here>
>
> Of course for that to happen you have to have a case, done with hard work
> on those frameworks and solutions, otherwise the shoot goes to your foot
> (and they will remember you as a bullshitter)
>
> This articles and discussions there are great to create opportunities for
> those who do cool stuff and have cases to show them up.
>
> That can create wealth.
>
> So, for those who do, that's the wrong time to remain silent and discrete
> and the right time to display what can be done.
>
> Act.
>
> If you can show cool stuff, act, case by case, it will elevates the whole
> niche and position you as a reference on that
>
> from mobile
>
> > On 09/01/2015, at 03:08, horrido  wrote:
> >
> > Well, I must say, my article really touched off a firestorm of
> controversy.
> > The Reddit thread is *very* active! Hacker News is also fairly lively.
> This
> > is where all of you do battle with the naysayers and critics.
> >
> > From my standpoint, my article did its job. It served as a lightning rod
> to
> > draw in developers from all over the world, from every other programming
> > language. *Now that we have their attention*, our job is to try our best
> to
> > persuade them.
> >
> > If we can "sell" Smalltalk to enough people, we gain mindshare. Companies
> > may hear about Smalltalk and possibly include it in their internal IT
> > discussions. Smalltalk may even get back on the TIOBE language index!
> >
> > We must keep the public discourse alive. I encourage you to blog about
> it,
> > write articles about it, comment on social media sites, etc. Because once
> > things settle down, they will /forget/ about Smalltalk...again.
> >
> >
> > horrido wrote
> >> Yes, I posted to both Reddit and Hacker News simultaneously. Looks like
> it
> >> has a slower uptake at Hacker News:
> >> https://news.ycombinator.com/item?id=8856503
> >> 
> >>
> >> Is it possible that I've finally succeeded in igniting a revolution? I
> >> feel like Che Guevara.
> >
> >>
> >> sebast...@flowingconcept.com wrote
> >>> It was posted already on Hacker News or Reddit?
> >>>
> >>> If not, it sounds like is the right time to do that
> >>>
> >>>
>  On Jan 8, 2015, at 5:03 PM, horrido <
> >
> >>> horrido.hobbies@
> >
> >>> > wrote:
> 
>  WHOA! My article is *ON FIRE!* Seven hours into publication and it has
>  achieved a staggering 2.7K views, 1.1K reads, and 9 recommendations.
>  It's
>  catching up to my best article ever, " The Case for Go Web Frameworks
>  <
> https://medium.com/@richardeng/the-case-for-go-web-frameworks-a791fcd79d47
>  <
> https://medium.com/@richardeng/the-case-for-go-web-frameworks-a791fcd79d47>
> ;>
>  ", which had 3.9K views and 2.4K reads.
> 
>  Who would've thought that Smalltalk would be such a hot topic?! I am
>  truly
>  flabbergasted.
> 
> 
>  horrido wrote
> > In
>  *
> > the 3 hours
>  *
> > since this article was published at Medium, it has garnered
>  *
> > 178 views
>  *
> > and
>  *
> > 96 reads
>  *
> > , and counting! This makes it easily the most "hot" article I've ever
> > written. It is currently at the top of
> > Medium's front page ;
> > which is reserved for "hot" or "trending" articles.
> >
> > Thanks to everyone!
> > horrido wrote
> >>
> https://medium.com/@richardeng/the-smalltalk-revolution-ee245c281f51
> >> <
> https://medium.com/@richardeng/the-smalltalk-revolution-ee245c281f51>;
> >>
> >> I welcome your comments. It's not too late to edit the piece.
> >>
> >> Thanks.
> 
> 
> 
> 
> 
>  --
>  View this message in context:
>  http://forum.world.st/The-Smalltalk-Revolution-tp4798320p4798436.html
>  <
> http://forum.world.st/The-Smalltalk-Revolution-tp4798320p4798436.html>;
>  Sent from the Pharo Smalltalk Developers mailing list archive at
>  Nabble.com ;.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/The-Smalltalk-Revolu

Re: [Pharo-dev] [ OT ] Je suis Charlie

[S Krish]

That indeed is absolutely true.

http://www.jiddu-krishnamurti.net/en/education-and-the-significance-of-life/1952-00-00-jiddu-krishnamurti-education-and-the-significance-of-life-1-education-and-the-significance-of-life


-Je suis Charlie..


On Fri, Jan 9, 2015 at 1:41 AM, stepharo  wrote:

> tx!
> Education is the only way.
>

Re: [Pharo-dev] The Smalltalk Renaissance Program

[S Krish]

*Wishes for a great new year for Pharo.. !..*

Subjective topics are the easiest to waste one's effort on, though are
essential in their own way, if we restrain ourselves. Pharo to me is headed
in the right direction with the right evangelists at its core. There should
not be a dilution to it in any pursuit.

a) PR and spreading the awareness is important to a pursuit of increasing
usage of the technology but not essential.

b) For a software platform ( again I say Pharo / Smalltalk is a platform
not a langauge ), it is question of :

Success is not from Pharo Platform per se but from its* usable frameworks:*

* Seek success organically, evolve to be the best fit for enterprise
programming, this can be through any of Seaside, Teapot+Zn, Glamour
toolkit, Jun, Open CL/R other interfaces, R Pi custom OS, etc.. or as in
mega framework like OpenStack in Pharo weaving in existing elements of the
mega framework for now.. et als. Make the framework use simple, scalable,
flexible that it is viral in its growth for the programmers.

   * Small business application ( not helloworld ) should be say a  1-3 hr
work with documentation given.  Rails promised that hiding its complexity
to user discovery but by then the user is hooked on enough to provide his
inputs / improve the framework. I liked the Teapot, Amber need to push more
around that kernel to make it scale upto creating a full application
framework deployable in 3 hrs.

*Pharo Platform:*

   * The platform offers stable and guaranteed behavior across fundamentals
of operations (all of CPU/ Mem/ OS resource use et als ), security
specially that ensures programmers can easily convince the CEO/CTO's to
allow their pet projects to be integrated. Gaps will exist and programmers
will fulfill it and grow the frameworks. Make the users feel as both
"winners" and "owners" in using the frameworks. Yes we need visionaries to
lead those frameworks.

* Make it as modular as possible to be able to use it just plain
commandline, with or without UI and its varied tools but with any of the
packages with dependencies that are well structured and easily updateable.

* The platform if it targets the enterprise will have to target
enterprise interfaces viz: DBMS, MQ, WS , deployment through easy
integration with Apache webserver or other common platforms. This is an
incremental goal driven by state of Pharo now and overal ecosystem of its
platform progressing together.

*PR:*

* Seek to push what you have to others through PR, at best this can
only be adjunct to the above, will probably yield some benefit but will not
be the raison-de-etre of the success of a product. Infact one part of PR I
believe works ( not something many intellectuals prefer) create sub-forums/
sub-committees and make more and more people be part of it.

   * I would much rather prefer having a website that showcases each
enterprise use like in Seaside the web application framework. But what the
seaside site lacks is a complete brief on deploying a web app end to end
with DBMS integration, easy css, js, et als integrated in 1 - 3 hrs, fairly
customized to my first prototype I require. Similar focussed sites should
exist that can be simple 1-2-3 instruction for the helloworld and scale up
quickly within a day to a workable app customized for requirement. Most
important leverage as much of pre-existing skills as in HTML, CSS, JS, MQ,
DBMS, ORM et als.. rather than create a new learning curve of the
developer. The kernel should be a killer feature as in Seaside/ Teapot but
they need to keep the continuum.. while taking the high ground




Let me put my hands on some of these efforts and then talk more. I am
greatly interested in pushing Pharo to enterprise use atleast for a
personal pursuit, let this new year resolution be to see that happens
before the year runs out.



On Fri, Jan 2, 2015 at 10:01 AM, horrido  wrote:

> Smalltalk isn't the ultimate language for me, either. I happen to like Go a
> lot. And it's conceivable that someone may come up with another truly great
> programming language in the future.
>

Re: [Pharo-dev] Jun4Pharo so exciting :)

[S Krish]

Originally OpenGL package in VW Smalltalk

On Tue, Dec 30, 2014 at 12:50 AM, Sven Van Caekenberghe 
wrote:

>
> > On 29 Dec 2014, at 15:36, stepharo  wrote:
> >
> > https://www.youtube.com/watch?v=sH_P5otiWJM&feature=youtu.be
>
> It certainly looks nice, but what is Jun exactly ?
>
>

Re: [Pharo-dev] The Smalltalk Renaissance Program

[S Krish]

Inlined notes

I agree nothing earth shaking is happening in Smalltalk in just the 6
months, but over the last 4 yrs it is a quite a shift in Pharo. Hats off to
all active contributers.

I quite disagree... on the fact nothing is happening. While all
intellectually inclined love the idea of creating anew something ground
breaking, it is in current decade more important to ensure we create
relevant technology not just for the sake of claiming high ground.

Wolfram , Google, FB may be creating their islands of tech bubbles and that
may take the world too, but they have the billions I guess to afford.


On Mon, Dec 29, 2014 at 6:06 AM, horrido  wrote:

> Bret Victor's talk is certainly interesting. This got me thinking...
>
> What we need is a modern-day PARC with a /next generation/ of visionaries
> to
> advance Smalltalk. They would carry on the work that was begun four decades
> ago.
>
> Here's the thing:  The Smalltalk environment has not fundamentally changed
> or improved since the Xerox PARC days. We've been tweaking the design here
> and there, but nothing groundbreaking has happened.
>
> Is the current Smalltalk environment the /final word/ on the nature of
> dynamic programming and humane representation of thought? I seriously doubt
> it.
>
> Who are the visionaries that will shake things up? How do we find them?
>

Stephane Ducasse and team are visionaries in as much as Pharo is
shaking things up on Smalltalk world .
Lots of new things have already been charted out, of course the tough
grind of actually cleaning and providing a meaningful free Smalltalk
environment for the enterprise world is a gargantuan task and I see it as
being reached gradually in Pharo. That will itself be etched in history 10
yrs later as a great achievement.

>
> Let's face it:  We've all become rather complacent. (With the exception of
> Newspeak, which frankly doesn't impress me much. *We don't need a new
> language!*)
>
> For four years I have seen the kind of energy/ enthusiasm unmatched
in the last decade or more in Pharo resurgence. Free Enterprise Smalltalk,
is about arriving in the IT industry.. just some honchos need to weave it
in.


> This is something Smalltalk Renaissance should think about.
>
> Much said and done in Pharo, there is nothing stopping any group in
> creating something more powerful / relevant and leave the footprints in the
> sands of time more firmly etched. I agree again there is lot of scope
> provided that group does it..
>
> --
> View this message in context:
> http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797243.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] The Smalltalk Renaissance Program

[S Krish]

What about joining up with Smalltalk Foundation , STIC and ESUG ..

Though laudable an initiative in whatever form you launch it.  Just may
give it a better thrust if there is joining of hands. Smalltalk has not in
the past gained with multiple directions / efforts. Pull all efforts in as
much as possible single basket.

Thanks and best wishes in the endeavour.


On Sat, Dec 27, 2014 at 11:08 AM, horrido  wrote:

> Do a search for Smalltalk resources, such as books, videos, tutorials,
> blogs,
> etc., and you will face a virtual avalanche of material. This can be
> overwhelming for Smalltalk newcomers to filter.
>
> Submit your favourite Smalltalk resources and I shall curate them and
> choose
> the best ones to place on our Resources page:
>
> http://smalltalkrenaissance.wordpress.com/resources/
> 
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4797114.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.

[S Krish]

Nice work.. !

DDS = Corba repackaged. Hopefully for the better... need to dig in to see
how easy it is now.

On Tue, Dec 2, 2014 at 3:41 AM, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

> Hi guys, i am just releasing SimpleDDS.
>
> In order to connect into ROS world i had to implement a DDS support
> (Publisher/subscriber).
>
> For achieving this i did  MetaDDS, a library that defines basic objects,
> announcements, event related mechanisms and data encoding formats, and on
> top of it SimpleDDS, which is ROS based.
>
> SimpleDDS Has a package of examples highly commented for learning how to
> use it.
>
> The comments are also in the Github wiki, as wiki pages:
>
> https://github.com/sbragagnolo/SimpleDDS/wiki
>
> Gofer it smalltalkhubUser: 'sbragagnolo' project: 'SimpleDDS';
> configuration; loadVersion: #stable
>
>
>
> Here some links about
>
> http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
>
> http://en.wikipedia.org/wiki/Data_Distribution_Service
>
>
> Thats it. Enjoy.
>
> Santiago
>
>
>
>
>

[Pharo-dev] MVC/ MVP / DCI Patterns..

[S Krish]

In the context of spec / UI / enterprise solutions, I have been mulling over 
this for some time especially when I play with FXML.

To put it in context, I find FXML intriguing and nice. XML metadata that stays 
completely outside the code and makes it uber flexible to weave in UI to a 
enterprise solution post facto.

The thought trail I have is:

Typical Pattern:

Model links to  Controller that links to a:  Customer View ( singleton ? )
Controller links to:  Validators / Delegates.. et als..

Model links to in Memory Cache registry { that links to: Persistence Module.. I 
do not bother about this for now..}

In FXML I see nice convention over configuration approach:

* XML format.. understood by people/ more importantly editors at large..
* Controller is injectable
* all method calls onAction/ events are simple viz #handleSubmitButtonAction or 
the ilk.. that will thereby call the controller instance methods..
* fxml can also invoke simple ( or complex) javascript action viz: 
jsSubmitAction( event)  

Would Spec see that kind of approach.. feasible for extensibility

Food for thought more as rethink on fundamental patterns:

a) Should view have knowledge explicitly of its Controller.. Or
Controller while creating the view injects its instance..  only.. 

b) Should we push Controller to be a Presenter.. as the case tends to be. And 
then let Controller be the gateway to all other parts.. as listed above..

c) View actions & callbacks & validators are separated and dealt with a view 
"controller" , but the gateway to all other parts is handled by a real 
"observer controller"

... There has to be reliable:

* bidirectional update from view -> model ( in cache )
* proper modular segregation of all parts of a standard enterprise app. to 
enable common and known functions of each part, flexible, scalable but 
importantly easily maintainable.. in future by developer other than the author..
* Scriptability is one of the desired capabilities with the shrink wrapped app 
to be extended 

Re: [Pharo-dev] [ANN] NetGen - OSM Roassal Demo

[S Krish]

Really nice, useful work.. inspires lot more confidence in Pharo.. its live
and programmable env.

On Thu, Nov 20, 2014 at 3:10 AM, Onil Goubier 
wrote:

>
> Hi all,
>
> We are pleased to announce a wireless sensor network animation demo in
> Pharo, Roassal and OpenStreetMap.
>
> https://github.com/OnilGoubier/Cirela
>
> The release contains 2 packages:
> 1. Cirela-OSM Package consists of the visualization of geographical
> information using roassal with  OpenStreetMap as background.
> 2. Cirela-Netgen-Sim: this package allows the execution of a synchronous
> and concurrent Wireless Sensor Network (WSN) simulation program [1] from
> Pharo. Outputs of the simulation are then animated on a map visualizing the
> locations of the simulated sensors.
>
> A video of the animated wireless sensor network simulation:
>
> https://www.youtube.com/watch?v=sMB7DG-lbiU
>
> Another video showing Cirela-OSM:
>
> https://youtu.be/6zoGIsQaGUo
>
> A word about CIRELA
>
> CIRELA (Communication and Information technology for REsiLience to
> disAsters) is a non profit NGO aiming at providing open source solutions to
> monitor and prevent natural and environmental disasters. Currently we are
> focusing on wireless sensor network monitoring and warning systems.
>
> [1] This program is generated in Occam by NetGen, from B. Pottier et al.
> (UBO)
>
>
> Regards,
> Onil
>
> --
> Onil Goubier
> Engineer
> CIRELA Association
> Communication and Information technology for REsiLience to disAsters and
> climate change
> 25, rue Paulhan
> 78140 Vélizy-Villacoublay, France
> Ph. +33 6 67 77 49 93
>

Re: [Pharo-dev] [smalltalk-research] Re: Julia vs Pharo

[S Krish]

Great read:

Picking some elements from Julia might take lesser time..

I pick on at a first look:

1. Express: http://bogumilkaminski.pl/files/julia_express.pdf
Quick deep dive in 1 hour..!

Also: http://forio.com/labs/julia-studio/tutorials/advanced/1/ .. cool
collection of tutorials following it just teaches everything about Julia
gripping one like a fiction novel..

2. Data Frame: http://www.r-tutor.com/r-introduction/data-frame

3. Single package.. : all of these, perhaps auto pulls in four packages..
"reading a delimited file / xls into an array, reading a delimited file/
xls into a DataFrame and accessing databases using ODBC."
readdlm, readcsv: read from file..
writedlm, writecsv: read from file..

4) Readability of a whole file:
 Remember Peter Deutsch's comment over a dinner: Smalltalk does not
have readability over the whole class in one go..
 Now if we can also have a display in our Nautilus browser of the whole
class in one read only browse mode with all methods as in Julia:

   // all variables
   classVariables =   classVar1 , classVar2...
   instanceVariables =  instVar1 , instVar2 ..

// all class side..
class function  init()
  
 end

 //all instance side
 function inst1()
  .
  end


  **  Easy interface with C / Fortran /  Python.. pyplot for instance.. and
JavaCall with in proc JVM..



On Sun, Nov 16, 2014 at 9:12 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> On Sun, Nov 16, 2014 at 1:45 AM, Alexandre Bergel
>  wrote:
> > Hi Serge!
> >
> > Thanks for sharing this.
> >
> > I indeed believe that scientific computing will play a big role in Pharo
> adoption by a large public
>
> The problem is that you need to invest at least 5 years of work before
> having some impact in this domain.
>
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Help fight Ebola by joining the Computing for Ebola Challenge
> http://bit.ly/1oEdBag
>
>

Re: [Pharo-dev] [Article] Lambda Calculus in Pharo

[S Krish]

Nice ...

On Thu, Nov 13, 2014 at 9:24 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> I was hacking a bit and one thing let to another and I ended up writing
> and publishing another short article:
>
>   Lambda Calculus in Pharo
>
>   Yes, the Y Combinator is useful in normal programs
>
>   https://medium.com/@svenvc/lambda-calculus-in-pharo-a4a571869594
>
> Enjoy,
>
> Sven
>
>
>

Re: [Pharo-dev] PharoNOS

[S Krish]

Guess this was couple of years back..

TCL + Pharo on a Virtual Box: My play with it then..

https://plus.google.com/photos/101656219013170129431/albums/5717749739476813505?banner=pwa



On Fri, Oct 17, 2014 at 9:52 AM, S Krish 
wrote:

>
> Lovely... TCL + Pharo .. !
>
>
>
>
>
> On Fri, Oct 17, 2014 at 7:17 AM, mikefilonov 
> wrote:
>
>> Hi Torsten,
>>
>> Yes sure I can. So this PharoNOS is basically TinyCore Linux with pure X
>> server and Pharo running in fullscreen.
>>
>> I have made some auto-installation scripts which configure the disk so no
>> setup wizard is needed. All space available is mounted under
>> /mnt/universe/
>> so you may use that folder to store stuff. Everything else is stored in
>> memory. Nice side effect of this is an ease of update as you may just
>> replace the ISO and you'll get the new version of everything (except of
>> the
>> image of course).
>>
>> Image is chosen on start by reading the "/mnt/universe/image" file. You
>> may
>> upload other image and change this file so after reboot it will start
>> with a
>> new one. No safeguards here though - if it breaks there is no cure for it
>> yet :( I'm thinking over on how to implement some recovery on "Image not
>> available or broken". Hm, just now get the idea to run Image chooser if
>> default image failed. Is it available on linux?
>>
>> Jan Tomsa  has pointed out  that the disk setup is quite dangerous
>> (https://twitter.com/DetektivTomy/status/522860736155238401) I plan to
>> update it later today with more safe solution which will not erase all the
>> data. The idea is to format the disk without a partition table or to work
>> from RAM. Also I think Pharo should be run under root user so you can bind
>> to any port.
>>
>> I can also put more 3d-party libs like sqlite3, so we can have some
>> interesting apps for the terminals run on embedded Pharo :) However I need
>> some feedback on what is needed.
>>
>> So that is it, all comments are welcome.
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/PharoNOS-tp4784982p4785034.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>

Re: [Pharo-dev] PharoNOS

[S Krish]

Lovely... TCL + Pharo .. !





On Fri, Oct 17, 2014 at 7:17 AM, mikefilonov  wrote:

> Hi Torsten,
>
> Yes sure I can. So this PharoNOS is basically TinyCore Linux with pure X
> server and Pharo running in fullscreen.
>
> I have made some auto-installation scripts which configure the disk so no
> setup wizard is needed. All space available is mounted under /mnt/universe/
> so you may use that folder to store stuff. Everything else is stored in
> memory. Nice side effect of this is an ease of update as you may just
> replace the ISO and you'll get the new version of everything (except of the
> image of course).
>
> Image is chosen on start by reading the "/mnt/universe/image" file. You may
> upload other image and change this file so after reboot it will start with
> a
> new one. No safeguards here though - if it breaks there is no cure for it
> yet :( I'm thinking over on how to implement some recovery on "Image not
> available or broken". Hm, just now get the idea to run Image chooser if
> default image failed. Is it available on linux?
>
> Jan Tomsa  has pointed out  that the disk setup is quite dangerous
> (https://twitter.com/DetektivTomy/status/522860736155238401) I plan to
> update it later today with more safe solution which will not erase all the
> data. The idea is to format the disk without a partition table or to work
> from RAM. Also I think Pharo should be run under root user so you can bind
> to any port.
>
> I can also put more 3d-party libs like sqlite3, so we can have some
> interesting apps for the terminals run on embedded Pharo :) However I need
> some feedback on what is needed.
>
> So that is it, all comments are welcome.
>
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/PharoNOS-tp4784982p4785034.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] creating custom browsers out of GTInspector extensions

[S Krish]

Really Cool...!



On Wed, Oct 15, 2014 at 11:52 AM, Marcus Denker 
wrote:

>
> > On 14 Oct 2014, at 23:26, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Now, that more people are playing with the GTInspector, I would like to
> raise another point that might otherwise go unnoticed: The inspector
> extensions do not only work in the inspector, but can also be combined in
> other browsers as well.
> >
>
> We could replace (most of) the FileBrowser by
>
> GLMPager new with: [ :pager |
>  pager show: [ :composite :file |
>   composite title: file basename.
>   file gtInspectorItemsIn: composite.
>   file gtInspectorContentsIn: composite ];
> title: 'FileBrowser' ];
>  openOn: FileSystem disk workingDirectory
>
>
>
> Where it replaces
>
> FileList linesOfCode
>
> ==> 1075
> (plus three more helper classes).
>
> Of course this does a little bit more, but most of that is at the wrong
> spot anyway.
> (editor for text files, API for file selection on the class side).
>
> Marcus
>

Re: [Pharo-dev] Tests around Pharo

[S Krish]

Using *cntlm *Proxy is an option in the cases where normal HTTP Proxy does
not work right


On Wed, Oct 15, 2014 at 5:26 PM, Sven Van Caekenberghe  wrote:

>
> On 15 Oct 2014, at 13:52, Christophe Demarey 
> wrote:
>
> >
> > Le 15 oct. 2014 à 13:01, Camille Teruel a écrit :
> >
> >>
> >> On 15 oct. 2014, at 12:35, mschepens 
> wrote:
> >>
> >>> After numerous tries, it was impossible for us to access to
> smaltalkhub from
> >>> our university at 11 o'clock, we'll try this evening or next days from
> our
> >>> personal connections.
> >>>
> >>
> >> Hi Mathieu,
> >>
> >> I teach at M5 this friday morning, so I can come to IAGL room around
> 12h15 to show you directly if you want.
> >> Tell me.
> >
> > It is just because University blocks all traffic.
> > They need to use an http proxy. I don't know if it is doable from a
> Pharo image.
>
> Sure, it is doable/available/working:
>
>   System > Settings > Network > Use HTTP proxy...
>
> But HTTP Proxies, especially weird or badly configured ones, are a known
> PITA.
>

Re: [Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19

[S Krish]

Tide is quite complete.. !!.. Didnt notice it at all.

Will try it out / perhaps compare it too to Flow.



On Mon, Oct 6, 2014 at 11:23 PM, Tudor Girba  wrote:

> Nice. Still, my question remains: how does it compare with Tide? Or better
> yet, would you not be interested in collaborating around Tide?
>
> Cheers,
> Doru
>
> On Mon, Oct 6, 2014 at 5:56 PM, Sebastian Sastre <
> sebast...@flowingconcept.com> wrote:
>
>>
>> - I’ve realized that this email was a social media done with email, cool
>> :)  BTW I think feeding a blog with this thread would be interesting, what
>> do you think?
>> - presented flow  at
>> CampSmalltalkVI2014, good reception, mostly offline but also slides have
>> ~360 views already
>> - added a couple of cool and very needed features to it (related to
>> double data-binding in the frontend)
>> - preparing to add some real-time features to it (in its Pharo backend)
>>
>>
>>
>>
>> On Oct 6, 2014, at 2:00 AM, seas...@rmod.lille.inria.fr wrote:
>>
>> Hi! We're sending this automatic email twice a month, to give the
>> community an opportunity to easily know what's happening and to coordinate
>> efforts.  Just answer informally, and feel free to spawn discussions
>> thereafter!
>>
>> ### Here's what I've been up to since the last WhatsUp:
>>
>> - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS
>>
>> ### What's next, until 2014-10-19 (*):
>>
>> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION
>>
>> (*) we'll be expecting results by then ;)
>>
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

[S Krish]

./startAll  first gave an permission denied error , changed to the
.hood/platform/linux folder to give permissions..

then it gave "Not implemented yet"

realize the startAll has just that echo..!.

lead me on a bit more..


On Mon, Oct 6, 2014 at 11:13 AM, S Krish 
wrote:

>
>
> The links has the step by step. I am running it as I type..
>
> * For newbies on linux a mention of dependencies viz installing git /
> curl/ npm , node.js and bower and any others reqd would be great..
>
> Anyways will post my attempt note in a few min..
>
>
>
> On Mon, Oct 6, 2014 at 11:06 AM, Sven Van Caekenberghe 
> wrote:
>
>> Great !
>>
>> Wasn't there a step by step tutorial somewhere ?
>>
>> On 05 Oct 2014, at 23:04, Sebastian Sastre 
>> wrote:
>>
>> > Hi guys,
>> >
>> > I’m sharing slides of my presentation at CampSmalltalkVI2014
>> > http://www.slideshare.net/sebastianconcept/flow-39897704
>> >
>> >
>> > From flow’s readme at github:
>> >
>> > Flow's mission is to provide consultants, startups and software houses
>> with a competitive Smalltalk full-stack framework that allows them to
>> quickly deliver a demo with all the modern html5 features the market
>> expects today (2014). The idea is that they can tactically use this
>> framework to keep momentum up among their prospects and clients and scale
>> things to full successful projects delivered by kickass productive teams or
>> individuals.
>> >
>> > sebastian
>> >
>> > o/
>> >
>> > blog: http://sebastianconcept.com
>> > LinkedIn: http://www.linkedin.com/in/sebastiansastre
>> > github: https://github.com/sebastianconcept
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>

Re: [Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

[S Krish]

The links has the step by step. I am running it as I type..

* For newbies on linux a mention of dependencies viz installing git / curl/
npm , node.js and bower and any others reqd would be great..

Anyways will post my attempt note in a few min..



On Mon, Oct 6, 2014 at 11:06 AM, Sven Van Caekenberghe  wrote:

> Great !
>
> Wasn't there a step by step tutorial somewhere ?
>
> On 05 Oct 2014, at 23:04, Sebastian Sastre 
> wrote:
>
> > Hi guys,
> >
> > I’m sharing slides of my presentation at CampSmalltalkVI2014
> > http://www.slideshare.net/sebastianconcept/flow-39897704
> >
> >
> > From flow’s readme at github:
> >
> > Flow's mission is to provide consultants, startups and software houses
> with a competitive Smalltalk full-stack framework that allows them to
> quickly deliver a demo with all the modern html5 features the market
> expects today (2014). The idea is that they can tactically use this
> framework to keep momentum up among their prospects and clients and scale
> things to full successful projects delivered by kickass productive teams or
> individuals.
> >
> > sebastian
> >
> > o/
> >
> > blog: http://sebastianconcept.com
> > LinkedIn: http://www.linkedin.com/in/sebastiansastre
> > github: https://github.com/sebastianconcept
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

[S Krish]

Abs great .. !..  https://github.com/flow-stack/flow have yet to install
and check if it has any issues in my system.

Will check it out, infact have a hackathon to see if this can be tried out
on it.

Nice framework to demo Smalltalk to the crowd in a banking world..



On Mon, Oct 6, 2014 at 2:34 AM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

> Hi guys,
>
> I’m sharing slides of my presentation at CampSmalltalkVI2014
> http://www.slideshare.net/sebastianconcept/flow-39897704
>
>
> From flow’s readme at github :
>
> Flow's mission is to provide *consultants*, *startups* and *software
> houses* with *a competitive Smalltalk full-stack framework* that allows
> them to quickly deliver a demo with all the modern html5 features the
> market expects today (2014). The idea is that they can tactically use this
> framework to keep momentum up among their prospects and clients and scale
> things to full successful projects delivered by kickass productive teams or
> individuals.
>
> sebastian 
>
> o/
>
> blog: http://sebastianconcept.com
> LinkedIn: http://www.linkedin.com/in/sebastiansastre
> github: https://github.com/sebastianconcept
>
>
>
>
>
>

Re: [Pharo-dev] Windows not interactive

[S Krish]

Little more context and details of your image and custom code  will be
required to give the advice.

Typically in Smalltalk it is advisable not to save the image with lots of
execution of your custom code, external call out done and then work with it
through many days, unless you are an expert enough to know your save is
save.

This may create situation leading to unstable behaviour including UI or
other areas.

On Fri, Sep 26, 2014 at 5:00 PM, Natalia Tymchuk <
natalia.tymc...@unikernel.net> wrote:

> Hi.
> I got the situation when all my windows are not interactive and when I
> click somewhere on windows and tabs the world menu appears. However I can
> open new window and work with it.
> What should I do in this situation?
> Best regards,
> Natalia
>

Re: [Pharo-dev] Spec license

[S Krish]

Thx..

Here I repost, an alternative framework to wire up Morphic UI:
* Implicit spec, full layout described spec and table layout based spec
options:

http://skrishnamachari.wordpress.com/2014/09/01/reviving-pharo-morphic-view/

Model / View / Controller hooks exists, the additional parts of the 2012
works, needs to be refactored for Pharo 3.0 and will be posted later.
Specially the ValueHolder capability for all morph widgets.

The framework works on 3 base and minimal support classes on top of the
existing morphic framework.





On Fri, Aug 29, 2014 at 1:43 PM, stepharo  wrote:

>  Hi skri
>
> Glenn is also working for a company and building an alternative to Spec to
> support mobile and others. What is important is that
>
> - we should continue to clean and improve spec and its documentation.
> - understand and push alternative solutions
> - so I suggest that you should make sure that other people can use
> what you are doing and continue to
> push it.
>
> Nothing is curved on stones.
> I clean Morphic regularly but I will be happy to through away all my work
> if something better is coming (bloc for example).
>
> Stef
>
>
>
> On 28/8/14 15:21, S Krish wrote:
>
>
>  Will there be any interest in alternative declarative framework, mostly
> fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et
> als in 3.0
>
>
> http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/
>
>  I can push this in with the required MIT license sign off as reqd.
>
>  More importantly, move this framework to a more refactored cleaner state
> if there is a slight interest in alternatives.
>
>
>
> On Thu, Aug 28, 2014 at 5:51 PM, p...@highoctane.be 
> wrote:
>
>> No, it doesn't.
>>
>>  We can improve Spec in the core, why wouldn't we be able to?
>> We use it in a lot of the tools, so, there are plenty of samples and
>> documentation exists.
>>
>>  One can make sense of what's going on under the hood.
>>
>>  Have a look at: (this is for Pharo 3.0)
>>
>>  SpecInterpreter>>interpretASpec:selector: and ComposableModel +
>> NewValueHolder.
>> WindowModel is interesting to look into as well.
>>
>>  The "famous" NewValueHolder is of interest too.
>>
>>
>>  then implementors of defaultSpec provide a lot of specs to give to the
>> SpecInterpreter.
>>
>>  Then one wants to look into the Spec-MorphicAdapters to see how Spec
>> maps its view on things with underlying Morphs (e.g. check the
>> MorphicDiffAdapter).
>>
>>  We can only benefit by caring about this piece on our side, as there is
>> tremendous potential in being able to change the underlying system (e.g.
>> from Morphic to Bloc for example) in a piecemeal way, without breaking all
>> of the tools.
>>
>>  Phil
>>
>>
>> On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen <
>> henrik.s.johan...@veloxit.no> wrote:
>>
>>> Does it really matter?
>>> If the external repository gets successfully relicensed, or Benjamin
>>> publishes new improvements as a separate, GPL-licensed change set, the end
>>> result is the same;
>>> no improvement he makes will make its way back into the versions in Core.
>>>
>>> I may not know his reasons, but I can certainly respect his wish that no
>>> further contributions are included in a core distribution.
>>>
>>> Whether to maintain/improve the current, MIT-licensed versions in Core
>>> without him, or unload it all and point potential users to the external
>>> library, is a separate decision.
>>> Though, from previous attempts, I’d say the chances of success of an
>>> external UI-builder framework seeing actual use are rather slim.
>>>
>>> Cheers,
>>> Henry
>>>
>>> On 28 Aug 2014, at 12:16 , Stephan Eggermont  wrote:
>>>
>>> >
>>> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f3974c69314b7f#commitcomment-7540588
>>> >
>>> > I think the license might need further improvements.
>>> > I've taken a look at the commit history, and  it looks
>>> > to me like there is a licensing problem there.
>>> > I am no lawyer, so don't know what the
>>> > exact consequences of that are.
>>> >
>>> > The (MIT licensed) Pharo code was copied
>>> > to the repository without including the copyright
>>> > notice, as is required by the MIT license.
>>> >
>>> > For 

Re: [Pharo-dev] Spec license

[S Krish]

Will there be any interest in alternative declarative framework, mostly
fleshed out, worked in Pharo 2.0 / with little fixes for FileDirectory et
als in 3.0

http://skrishnamachari.wordpress.com/2012/01/31/pharo-application-framework-aka-morphic-view-framework/

I can push this in with the required MIT license sign off as reqd.

More importantly, move this framework to a more refactored cleaner state if
there is a slight interest in alternatives.



On Thu, Aug 28, 2014 at 5:51 PM, p...@highoctane.be 
wrote:

> No, it doesn't.
>
> We can improve Spec in the core, why wouldn't we be able to?
> We use it in a lot of the tools, so, there are plenty of samples and
> documentation exists.
>
> One can make sense of what's going on under the hood.
>
> Have a look at: (this is for Pharo 3.0)
>
> SpecInterpreter>>interpretASpec:selector: and ComposableModel +
> NewValueHolder.
> WindowModel is interesting to look into as well.
>
> The "famous" NewValueHolder is of interest too.
>
>
> then implementors of defaultSpec provide a lot of specs to give to the
> SpecInterpreter.
>
> Then one wants to look into the Spec-MorphicAdapters to see how Spec maps
> its view on things with underlying Morphs (e.g. check the
> MorphicDiffAdapter).
>
> We can only benefit by caring about this piece on our side, as there is
> tremendous potential in being able to change the underlying system (e.g.
> from Morphic to Bloc for example) in a piecemeal way, without breaking all
> of the tools.
>
> Phil
>
>
> On Thu, Aug 28, 2014 at 1:19 PM, Henrik Johansen <
> henrik.s.johan...@veloxit.no> wrote:
>
>> Does it really matter?
>> If the external repository gets successfully relicensed, or Benjamin
>> publishes new improvements as a separate, GPL-licensed change set, the end
>> result is the same;
>> no improvement he makes will make its way back into the versions in Core.
>>
>> I may not know his reasons, but I can certainly respect his wish that no
>> further contributions are included in a core distribution.
>>
>> Whether to maintain/improve the current, MIT-licensed versions in Core
>> without him, or unload it all and point potential users to the external
>> library, is a separate decision.
>> Though, from previous attempts, I’d say the chances of success of an
>> external UI-builder framework seeing actual use are rather slim.
>>
>> Cheers,
>> Henry
>>
>> On 28 Aug 2014, at 12:16 , Stephan Eggermont  wrote:
>>
>> >
>> https://github.com/spec-framework/spec/commit/07ea83ca50523b4a912e363ff2f3974c69314b7f#commitcomment-7540588
>> >
>> > I think the license might need further improvements.
>> > I've taken a look at the commit history, and  it looks
>> > to me like there is a licensing problem there.
>> > I am no lawyer, so don't know what the
>> > exact consequences of that are.
>> >
>> > The (MIT licensed) Pharo code was copied
>> > to the repository without including the copyright
>> > notice, as is required by the MIT license.
>> >
>> > For new contributions, you now have the
>> > license agreements, and with git it is
>> > perfectly clear what is new, and under
>> > the new license, and what is old, and
>> > can therefore also be used under the
>> > old license. And AFAIK MIT license
>> > is compatible with GPL.
>> >
>> > I have no clue as to the license status of
>> > changes between the copying and the
>> > relicensing.
>> >
>> > Of course copyright holding contributors can
>> > decide to relicense. The contributors to the
>> > Spec-* packages in the Pharo/Pharo30 repo
>> > seem to be:
>> >
>> > AlainPlantec
>> > AndreiChis
>> > BenComan
>> > BenjaminVanRyseghem
>> > BernardoContreras
>> > CamilloBruni
>> > CamilleTeruel
>> > ChristopheDemarey
>> > ClementBera
>> > DamienCassou
>> > ErwanDouaille
>> > EstebanLorenzano
>> > GabrielOmarCotelli
>> > GuillermoPolito
>> > HernanMoralesDurand
>> > IgorStasenko
>> > LeoGassman
>> > MarcusDenker
>> > MartinDias
>> > NicolaiHess
>> > PabloHerrero
>> > PavelKrivanek
>> > PhilippeBack
>> > RobertoMinelli
>> > SeanDeNigris
>> > SebastianTleye
>> > StephaneDucasse
>> > SvenVanCaekenberghe
>> > TorstenBergmann
>> > TudorGirba
>> > YuriyTymchuk
>> >
>> > Stephan
>> >
>> >
>> >
>> >
>>
>>
>

Re: [Pharo-dev] Quitting the community

[S Krish]

This reminds me of my 3 year stint in a French CAD firm, where I was
witness to many a technical tiff between a senior director and a really
fresh out of college engineer which will look as if its a personal ego
fight. But at the end of the day both will pick their bags and go off to
have a beer / dinner together and come back next morning as good as friends
they ever were.

It taught me in my middle age, arguments over work should never spill over
to personal ego.

But life is short and all of us carry ourselves the way we are
conditioned...!

What is right and wrong, is mostly not cast in stone, but when it becomes
contentious, it is just ok to give experience the right of way..


On Tue, Aug 19, 2014 at 6:07 AM, Igor Stasenko  wrote:

> P.S. regardless.. about the subject, so, now
>
> Here's an example
>
> nil asValueHolder
>
> shall be refactored to
>
> nil asReactiveVariable
>
> ?
>
> sounds like a plan :)
> 
>
> And yes, Ben, you are wrong, if you consider this as a personal attack.
> This code smells, to say it politely. But i prefer to call it crap.
> When i see such things, the only thing, which comes to my mind is: 'when
> the only tool you have is a hammer, you tend to treat everything as nail'.
>

Re: [Pharo-dev] Can forking speed up anything?

[S Krish]

http://stackoverflow.com/questions/5919172/gpgpu-vs-multicore

The answer is really nice.. over GPU/ multithreaded CPU et als. GPU is not
a panacea for enterprise programming, but for specific parallel
unbranched-no synchronization driven algorithms

* The worst code for GPU is code with less parallelism or code with lots of
branches or synchronization.

* Easily vectorizable code: CPU is easier to code but low performance. GPU
is slightly harder to code but provides big bang for the buck. For all
others, CPU is easier and often better performance as well.

* GPUs don't support interrupts and exception.



On Tue, Aug 5, 2014 at 1:00 AM, stepharo  wrote:

>
> On 4/8/14 19:46, Alexandre Bergel wrote:
>
>> Hi Yuriy,
>>
>> My advice is to use OpenCL. OpenCL is a standard to use the graphical
>> card to carry out massive computation.
>> The good news is that Ronie has worked on a binding between OpenCL and
>> Pharo. I am using it and it works pretty well.
>> http://smalltalkhub.com/#!/~ronsaldo/OpenCL
>>
>
> Alex
>
> first a good algorithm with a controlled complexity is important.
> If you have a naive algorithm you can wait that the Universe die
> before getting a result.
> I remember doing stupid algorithm that we speed up with roel from a
> couple of hours to 20 s.
>
> Second OpenCL binds you to system having openCL support and this is
> important to understand it.
>
> Stef
>
>>
>> Cheers,
>> Alexandre
>>
>
>
>

[Pharo-dev] Fwd: World Skills 2015 Sao Paulo

[S Krish]

I am not able to post to Pharo-users list..

Can anyone forward it.


-- Forwarded message --
From: S Krish 
Date: Thu, Jul 31, 2014 at 11:59 AM
Subject: World Skills 2015 Sao Paulo
To: A friendly place where any question about pharo is welcome <
pharo-us...@lists.gforge.inria.fr>



http://www.worldskills.org/index.php?option=com_content&task=view&id=1183&Itemid=680

Nice place to showcase Pharo as emerging technology if 21 and lesser
developers are coming up with projects on it..

Re: [Pharo-dev] Pharo is Smalltalk… and Not

[S Krish]

+1

I understand the part about making Pharo appeal more to the wider audience
in this decade and ahead

Let me put in the effort in making that happen, before I say another word
on this. Making a platform that I can be most productive in be the most
accepted one across the industry is a big win for me...




On Thu, May 1, 2014 at 2:20 AM, Sean P. DeNigris wrote:

> Here's my musings about how we integrate the two motives - to acknowledge
> our
> heritage /and/ break out of our pigeon hole. My key point here is to
> gradually introduce the Smalltalk part after people are deep enough to have
> gotten excited about the ideas without dismissing them because of cultural
> baggage...
>
> Drilling down:
> 1. Sound bite: "Pharo - The immersive programming experience"
> 2. Why Pharo: (about a paragraph, like the one on the site now, "Pharo
> gives
> you immediate and total control over your programming experience..."
> 3. What is it. Here we can accurately paint the nuanced picture,
> distinguishing Smalltalk as an idea based on design principles vs.
> Smalltalk-80. If "Smalltalk" more exactly means an environment + libraries
> +
> a language (I think that order is important - the syntax was always the
> least interesting thing about Smalltalk). What we might really say if we
> had
> the time to go beyond an initial sound bite is:
> Pharo is:
> - a [pick 2 or 3 of: dynamic, open, immersive, live] environment
> (like an
> IDE and OS rolled into one)
> - beautifully designed core libraries including a web
> client/server, FFI,
> Y, Z...
> - a dialect of the Smalltalk programming language
>
> For #1, the inspiration is most accurately the Dynabook
> For #2, IMHO enough components have been rewritten to stand on it's own
> For #3, this is where we are most obviously a Smalltalk, and should be
> clear
> about it
>
> And in an FAQ answer any common objections people might have:
> Q: Is Pharo Smalltalk?
> A: When most people hear "Smalltalk", they think of Smalltalk-80, which
> Pharo is not. However, Smalltalk is really an idea... the lineage of which
> Pharo is a proud member
> Q: Can I talk to the world outside the environment?
> A: Yes! While the original Smalltalk was quite insulated, now you can
> [interact on the command line](link to unix command line examples e.g. the
> very Ruby-like pharo [image filename] -e "self inform: 'hello world'"),
> [talk to C libraries](link to native boost), etc.
> yada yada yada
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Pharo-is-Smalltalk-and-Not-tp4757342p4757348.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[S Krish]

"So it's a question of who you're marketing to. Since we're marketing to
non-Smalltalkers (quite wise since 16% market penetration is the tipping
point [1], and we're not there yet)"

If you can get Pharo Smalltalk to be what makes people feel great about
using it and creating great applications with, it will succeed far more
than Ruby has in 5 years ahead. We need not push our efforts and energy in
labelling ( falsely ), that will give no impact / or add any value to the
perception of people.

Java succeeded because it enabled many to move on to the web enabled
world.. massively..

Rails succeeded because developers found it easier and simpler to bring up
a complete website and maintain it than its alternatives. JRuby helped in
as much Heroku did in its growth. Many developers made their fortune out of
Rails..

iPad, iPhone, iPod, now android phones / tablets succeed well and truly
because they enable the people to do what they want with it, make them feel
great about using them too and bigger bet was developing for the Appstore
and Android Market place that enabled many more to make money.

Can we move on to have a Pharo Appstore with a demand for the apps in the
store ... you will see more than 16% share you will need to make Pharo big.

http://skrishnamachari.wordpress.com/2014/04/29/pharo-is-a-smalltalk-dialect/





On Tue, Apr 29, 2014 at 5:54 AM, Sean P. DeNigris wrote:

> Tudor Girba-2 wrote
> > There is a point of view from which one could say that
> > Pharo is Smalltalk by seeing Smalltalk as a movement, rather than
> specific
> > implementation. Unfortunately, everyone else thinks of Smalltalk as a
> > specific language, or set of languages with specific environments that
> > typically look old enough to not be relevant anymore.
>
> Yes! This is a tower of babel argument.
> For almost every programmer alive, Smaltalk = Smalltalk 80 -> Pharo is
> Smalltalk-inspired
> For us, Smaltalk = "experimental Dynabook software that bootstraps itself
> (ideally every 4 years)" -> Pharo is Smalltalk 109.
>
> So it's a question of who you're marketing to. Since we're marketing to
> non-Smalltalkers (quite wise since 16% market penetration is the tipping
> point [1], and we're not there yet), clearly "Pharo is Smalltalk-inspired"
> is the thing to say. It's not any more or less true than the latter, just
> more useful in its context.
>
> [1] http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4756891.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] a Pharo talk from a ruby conference

[S Krish]

+1

Smalltalk heritage and its future should be carried on by "Pharo Smalltalk".


On Mon, Apr 28, 2014 at 11:08 PM, Eliot Miranda wrote:

>
>
>
> On Mon, Apr 28, 2014 at 10:20 AM, Tudor Girba wrote:
>
>> That is why we talk about Pharo as a cool, modern environment and
>> language that is Smalltalk-inspired.
>>
>
> We went through this a few months ago.  Pharo  isn't inspired by
> Smalltalk; it /is/ a Smalltalk.   Trying to be mealy-mouthed about it and
> claiming inspiration, rather than proudly declaring its a Smalltalk is IMO
> as bad as apologizing for it being dead.
>
>
>> We do not need to apologize because Pharo was never dead :).
>>
>
> We don't need to avoid the S word either...
>
>
>>
>> Doru
>>
>>
>> On Mon, Apr 28, 2014 at 7:16 PM, Norbert Hartl wrote:
>>
>>>
>>> Am 28.04.2014 um 18:58 schrieb kilon alios :
>>>
>>> very cool presentation. Definitely you need to add this to the new
>>> website.
>>>
>>> Question : Why in every presentation we have to apologise why smalltalk
>>> is dead / extinct ?
>>>
>>> As a newcomer to Smalltalk I find it quite annoying. Its not as if I
>>> came to Smalltalk without knowing that is not popular. The vast majority of
>>> languages out there are so more unpopular than Smalltalk, yet they don't
>>> have this "sorry that I am dead" mentality to them.
>>>
>>> +1
>>>
>>> Well said.
>>>
>>> Norbert
>>>
>>>
>>> On Mon, Apr 28, 2014 at 7:12 PM, Marcus Denker 
>>> wrote:
>>>
 … more a Smalltalk one using Pharo:

 MountainWest RubyConf 2014

 Noel Rappin: "But Really, You Should Learn Smalltalk”

 Smalltalk has mystique. We talk about it more than we use it. It seems
 like it should be so similar to Ruby. It has similar Object-Oriented
 structures, it even has blocks. But everything is so slightly different,
 from the programming environment, to the 1-based arrays, to the simple
 syntax. Using Smalltalk will make you look at familiar constructs with new
 eyes. We’ll show you how to get started on Smalltalk, and walk through some
 sample code. Live coding may be involved. You’ll never look at objects the
 same way again.


 http://www.confreaks.com/videos/3284-mwrc-but-really-you-should-learn-smalltalk

>>>
>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>
>
> --
> best,
> Eliot
>

Re: [Pharo-dev] Debugging in Production Servers

[S Krish]

The good developers / expert users will not do what you state. The eclipse
debug, inspector, watches are very much part of a normal dev cycle in our
place with around 100 devs.

Even in Smalltalk I have seen less capable developers not exploiting even a
fraction of the capability Smalltalk has and depend on loggers / prints to
transcripts and lot less use of reflection live to inquire and detect
issues faster.

The issue I explained is that the capability exists and is not exploited
due to process constraints in the industry even for Java, so Smalltalk
capability will not be seen as a killer feature per se even if its more
flexible and capable.

The reflection to dump more logger information is of course most welcome
but without adding any performance overhead at runtime except when the
error occurs.

I would further aver that all the Smalltalk capabilities are highly
leveraged in a dev environment and is capable of cutting dev time to one
third or even lesser in the hands of an expert.










On Thu, Apr 24, 2014 at 11:12 AM, Sven Van Caekenberghe wrote:

> I am sorry, but I disagree.
>
> Yes, technically, much of what we take for granted is partially possible
> in most other languages, but it is often hard to use, an add-on, an
> afterthought. But more important, Java developers even do not use
> debuggers/inspectors/browsers during development, let alone during
> production. It's just edit/compile/run/crash - add some print statements
> and run again. During production its all massive plain logging.
>
> We can dump live stacks with FUEL for example.
>
> On 24 Apr 2014, at 06:01, S Krish 
> wrote:
>
> > One can easily do that with Java / Eclipse or for VC++ / Visual Studio
> with attach to process. Probably I would reckon these to be more "secure"
>  as industry prefers rather than having live debug capabilities built in to
> the code delivered or somehow "in-process". I am sure all others as in
> python, ruby et als will have debug in prod capabilities if reqd.
> >
> > Javascript with Rhino also can easily allow live debug if the reqd jar
> is present..
> >
> > The bigger purchase Smalltalk gives is in reflection that can be
> leveraged to produce fairly extensive logger reports which no other
> langauge currently does when fault occurs in production.
> >
> > I doubt in production the industry is as of now willing to let debug be
> acceptable specially in Banking domain.
> >
> > The smalltalk advantages are not translating into business gains per se
> given the comfort zone of security, safety production systems are wrapped
> in procedurally.
> >
> >
> > On Thu, Apr 24, 2014 at 7:39 AM, askoh  wrote:
> > Smalltalk has the capability of allowing live debugging in production
> > servers. How unique is this capability? What other systems allow that?
> >
> > Is there a name for such capability? Can we coin one and market it?
> >
> > What are the pros and cons of having such a capability?
> >
> > All the best,
> > Aik-Siong Koh
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
> >
> >
>
>
>

Re: [Pharo-dev] Debugging in Production Servers

[S Krish]

The capability exists, any dev team can take advantage if reqd of it, I am
sure many may have in rare occassions. On the remote on the same LAN it
will not be any different than debug is for eclipse / VisualStudio in dev.

In Insurance, Banking in my experience, it will be the last resort, unless
it is critical and there is no other alternative to it but with production
data set.

As I reiterated the reflection based data gathering that can enabled along
with the superb exception handling capability it is something that is
leveraged by smalltalk in production ( Unicycle reports in VA) and that is
terrific for resolving bugs.

Reflection based tools like in Groovy can bring any Java system close to
Smalltalk offers also in production as I have done in my work place.




On Thu, Apr 24, 2014 at 9:50 AM, askoh  wrote:

> Thanks for reply. Are there cases of Java/Eclipse running in Production?
> Similarly with VC++ / Visual Studio? They would be very very slow wouldn't
> they?
>
> I am referring to real use case of live debugging in Production servers. I
> agree that this capability might not be attractive from point of view of
> security and safety. But there are insurance and financial companies that
> use Smalltalk. How do they view this capability? Do they forbid it totally?
> If they allow it, how do they prevent abuse?
>
> The pros is of course the easy of finding bugs and inspection of states
> during production.
>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context:
> http://forum.world.st/Debugging-in-Production-Servers-tp4756136p4756141.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Debugging in Production Servers

[S Krish]

One can easily do that with Java / Eclipse or for VC++ / Visual Studio with
attach to process. Probably I would reckon these to be more "secure"  as
industry prefers rather than having live debug capabilities built in to the
code delivered or somehow "in-process". I am sure all others as in python,
ruby et als will have debug in prod capabilities if reqd.

Javascript with Rhino also can easily allow live debug if the reqd jar is
present..

The bigger purchase Smalltalk gives is in reflection that can be leveraged
to produce fairly extensive logger reports which no other langauge
currently does when fault occurs in production.

I doubt in production the industry is as of now willing to let debug be
acceptable specially in Banking domain.

The smalltalk advantages are not translating into business gains per se
given the comfort zone of security, safety production systems are wrapped
in procedurally.


On Thu, Apr 24, 2014 at 7:39 AM, askoh  wrote:

> Smalltalk has the capability of allowing live debugging in production
> servers. How unique is this capability? What other systems allow that?
>
> Is there a name for such capability? Can we coin one and market it?
>
> What are the pros and cons of having such a capability?
>
> All the best,
> Aik-Siong Koh
>
>
>
> --
> View this message in context:
> http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [Inspiration] Toward a better programming

[S Krish]

"...Coherent and robust philosophy..."

We got to be aware of the fact that Wolfram is recognized as a renegade
scientist with a great work in Mathematica but the work on cellular
automata and his theory on New kind of Science is controversial to put it
lightly.

What appeals to me as ideas / concepts that will make a great impact in
Pharo if we can bring it in, without crossing swords on IP / patents..!!..
Kind of pick on priori art on all of them.

http://www.wolfram.com/language/principles/

*For Pharo:*

The great work done in Pharo so far and with core roadmap ahead.. this will
probably be add on to the core / or as an extension:

*  *Cloud/ distributed processing*: A semi connected distributed language /
programming environment that is knowledge aware of each node, scalably
working with one or more nodes available at any given time. Backend data
awareness linked to any type of data storage: RDBMS, NoSQL, flat files..

*  *Power of algorithmic computation:* The framework for distributed AI
algorithm that works with available knowledge base in time defined manner (
synchronous or asynch ) of the defined "execution". The power user can then
plugin additional algorithms, modify and create a web as reqd

*  *Symbolic Expressions*: Syntactically cryptic but like a DSL it makes
sense to have power user the brevity in his daily grind, though it can be
left to the power user group to evolve the same given a foundation of a
framework that makes it quick work to get it stitched together.

* * Flexible Presentation*: DSL or the scripting driven quick presentation
capability that can be any from a html / morphic / image / video / textual
presentation. Kind of moldable, flexible to the core with defaults that
feel almost intuitive to the processing

*  *NLP*: Natural language processing that is incremental, perhaps
smalltalk already has been there in a small measure and static for a very
long time, need to make it really NLP..
http://emerge.mc.vanderbilt.edu/natural-language-processing-nlp-survey-tools-resources
<http://www.nltk.org/>

*  *Numerical computation*: Fast, highly efficient perhaps Native Boost
enabled all kinds of maths: calculus, statistical computation, image
processing et als.

All the above are greatly relevant in the enterprise world development and
will be a great fit to Pharo's capability with the GTInspector,
Rossal+Athens presentation along with Morphic, meta programming, debugger
that is live and can be interconnected with fuel, syntatically as close to
NLP to any mainstream language can be ...


*-Skrish*


On Wed, Apr 2, 2014 at 11:42 AM, Tudor Girba  wrote:

> Indeed, I read this article several times over the last couple of days.
> This work is impressive particularly when combined with the cloud part.
>
> The language itself is less interesting for me, but what makes it stand
> out is that it has a coherent and robust philosophy behind and phenomenal
> goals to reach. In Pharo, we have the luxury of building on top of coherent
> and robust philosophy (even if different from the Wolfram one) and we
> should try as much as possible to keep our eyes on phenomenal goals that
> seem unreachable.
>
> Another thing I like in Wolfram's work is attention to details:
> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/
>
> Details are crucial, and all the effort in Pharo around naming and
> redesigning what already exists is incredibly important. But, it is
> precisely at the moment when we are knee-deep in details that is crucial to
> keep our eyes on the phenomenal long term goals.
>
> There is so much to build. Let's be bold.
>
> Doru
>
>
>
> On Tue, Apr 1, 2014 at 7:22 PM, Sven Van Caekenberghe wrote:
>
>>
>> On 31 Mar 2014, at 06:21, S Krish 
>> wrote:
>>
>> > How about impact of this:
>> >
>> >
>> http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sxsw-update/
>> >
>> > I would agree it is quite complex for any beginner, but utility of a
>> programming language on these lines seems cut out for the future..
>>
>> Wow, this is really powerful stuff, a long read, but well worth it. By
>> recombining and reusing all their technology they seem to be able to move
>> into more and more territory.
>>
>> It is closed source and (very) expensive, and I don't like the syntax,
>> but we sure can get good ideas from them.
>>
>> Thanks for sharing the link.
>>
>> Sven
>>
>

Re: [Pharo-dev] [Inspiration] Toward a better programming

[S Krish]

How about impact of this:

http://blog.stephenwolfram.com/2014/03/injecting-computation-everywhere-a-sxsw-update/

I would agree it is quite complex for any beginner, but utility of a
programming language on these lines seems cut out for the future..




On Mon, Mar 31, 2014 at 6:56 AM, Alexandre Bergel
wrote:

> I cannot resist to jump on this. Indeed, we have the moral obligation to
> promote what we have crafted over the year.
> Producing a high-quality video has been on my todo list for quite some
> times already. As you probably know, we did some intent already (videos
> about Roassal, GraphET, and other tools), but we were too young maybe.
>
> Within the next few weeks we will work on a cool video to promote
> Roassal2, and our goal is to reach users beyond the Smalltalk boundary. We
> have everything so far. The moose distribution is a wonderful toolbox that
> can literally blow away any example shown in this video.
>
> As you may have seen, we have worked on Roassal2 which includes a new
> geographical map builder, tabular table importer, GraphET2, fancy curves,
> html and amber exporter. A video carefully orchestrated has the potential
> to kick away Aurora, Light Table, Wolfram and all their friends.
>
> We will soon get there...
>
> Alexandre
>
>
> On Mar 29, 2014, at 2:20 PM, Tudor Girba  wrote:
>
> > Beautiful demo. This should be our game, yet others are playing it :(.
> >
> > Doru
> >
> >
> > On Sat, Mar 29, 2014 at 11:31 AM, Sven Van Caekenberghe 
> wrote:
> >
> > On 29 Mar 2014, at 10:38, Sven Van Caekenberghe  wrote:
> >
> > > This is a nice write down:
> > >
> > >  http://www.chris-granger.com/2014/03/27/toward-a-better-programming/
> > >
> > > with a nice demo of a prototype:
> > >
> > >  https://www.youtube.com/watch?v=L6iUm_Cqx2s
> > >
> > > Luckily, the horrible C++ code computing standard deviation in the
> article can be written quite elegantly and directly in Pharo:
> > >
> > > | input |
> > > input := #(2 4 4 4 5 5 7 9).
> > > (((input - input average) raisedTo: 2) sum / (input size - 1)) sort.
> > >
> > > Sven
> >
> > Damn spelling correction ;-)
> >
> > | input |
> > input := #(2 4 4 4 5 5 7 9).
> > (((input - input average) raisedTo: 2) sum / (input size - 1)) sqrt.
> >
> >
> >
> >
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

[Pharo-dev] pharocloud.com

[S Krish]

Great work..!

Hope it grows leaps and bounds like Heroku or AWS..!

[Pharo-dev] Dev Art from Google

[S Krish]

Moose art visualizations if not more from Phratch et als can make a mark
here.


https://devart.withgoogle.com/?utm_source=email&utm_medium=gsp&utm_campaign=gspb

[Pharo-dev] Interesting link

[S Krish]

   1.

   Since then, Smalltalk (SqueakNOS ),
   Forth (colorForth ), and Lisp
(Genera)
   have all flirted with becoming operating systems, and
Oberon
was 
designed
to be one  from
   the start. But none achieved economic success, for the simple reason that
   none of the projects involved attempted to provide value to people. They
   solved technical problems to validate that their concepts can work in the
   real world, but did not pursue the delivery of better solutions to
   real-world problems than would otherwise be
possible.↩

Pharo hopefully corrects the course..

>From :
http://davidad.github.io/blog/2014/03/12/the-operating-system-is-out-of-date/

Most of all, let’s rethink the received wisdom that you should teach your
computer to do things in a programming language and run the resulting
program on an operating system. A righteous operating system should be a
programming language. And for goodness' sake, let’s not use the entire
network stack just to talk to another process on the same machine which is
responsible for managing a database using the filesystem stack. At least
let’s use shared memory (that’s what it’s *for*!). But if we believe in the
future — if we believe in ourselves — let’s dare to ask why, anyway, does
the operating system give you this “filesystem” thing that’s no good as a
database and expect you to just accept that “stuff on computers goes in
folders, lah”? Any decent software environment ought to have a fully
featured database, built in, and no need for a “filesystem”.

[Pharo-dev] Google Glass with Smalltalk

[S Krish]

https://developers.google.com/glass/tools-downloads/client-libraries


Is anyone working trying out Pharo API to Google glass?  Pharo-Android per
se being the base in this.

Re: [Pharo-dev] Playing an mp3

[S Krish]

Why not link Pharo to mpg through NB to have all the capability required.

I gave a shot at it a year back.. seems quite doable, will take about a
month's effort max for anyone..


On Thu, Feb 13, 2014 at 1:35 AM, kmo  wrote:

> As far as I know pharoSound only plays AIF and WAV. Phratch certanly has
> MP3
> playing abilities - but I've only tried it on Linux and MP3s do not play.
>
>
>
> --
> View this message in context:
> http://forum.world.st/Playing-an-mp3-tp4742737p4743093.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

[Pharo-dev] Fwd: Talk on Pharo In Enterprise Context

[S Krish]

Bounced from the Users List.. so posting to this forum for now..


I am planning on delivering a lecture-demonstration on Pharo Smalltalk in
specific and Smalltalk historically in our product

Through last 20 yrs the one premier product in the company has had
Smalltalk lineage from early Enfin days but  as of today it is
re-engineered in Java / Javascript going ahead for external plugins.

I am planning to focus on Smalltalk and major thrust is Pharo as the
upcoming base for real Enterprise platform of the future.

*Any ideas *on what can be demoed and talked of from Pharo and overall
simple or complex leaves an indelible impression of awe  in the minds of
many who actually perceive it as legacy..!..  many familiar but as the
enterprise world goes believe Java and C# is the platform for ages to come.

viz: concurrency as in Scheme / Closure / Hydra as in VW / something that
still hugely differentiates. *Any other inputs on the roadmap* that speaks
to its covering lost ground and compatability with "Legacy" World of Java /
C# not through SOA but simpler.


**

*Talk covers:*

* Few example patterns evolved in the product in Smalltalk now adorns the
Java code and serves well / better than various frameworks in JEE

* Smalltalk has lead the way for language evolution for decades with Java 8
now catching up with even features like closures et als. All the features /
capability that makes it still special..

* Javascript aka Live script was not Java and is more akin to Self
Smalltalk and how it has its right of way in the corporate world with Java
Rhino / Nashorn unwrapping it on the non browser side. Amber Smalltalk will
be demoed in this context.

* Bit of history and various dialects of Smalltalk

* Then come over through to Pharo and its demonstration.

  a) Need a perfect IDE setup that covers all demonstrable complex stuff:
Rossal / Moose as one, NB library as the other with Athens / SVG rendering,
MargritteDescription , Traits..? not aware of complex examples on it.

  b) Seaside demonstration..

... others..

Re: [Pharo-dev] [ANN] Phratch 1.0beta

[S Krish]

Jannik,

Just to let  you know, I had loaded Phratch on Pharo 3.0 few days back and
it worked fine at the basic levels.  It did throw the an error dialog but
continued to load and present the full screen of scratch. I will test it
further as it progresses..

( as someone else said, no harm moving to a attractive name for such a
beauty of a work ..)

Re: [Pharo-dev] Pharo magic

[S Krish]

Smalltalk has always been the crucible of inventions...

http://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html

 Pharo can take its rightful place in near future, amongst Java and C# to
give a credible choice for an interactive development platform.

 Dynabook with Pharo ..  as Kay imagined..? or adapted to be mass produced.

 I like the thought in mash-up of objects rather than standalone apps in an
App Store comment.





On Sat, Dec 7, 2013 at 3:22 AM, Marcus Denker wrote:

>
> On 07 Dec 2013, at 00:24, Nicolai Hess  wrote:
>
> > This seems to be a good place to introduce myself.
> >
>
> Welcome!
>
> > My Name is Nicolai Hess,
> > I follow the squeak (and pharo) community for some years (~10).
> > (Not as an *active* member in that time, but a little bit more the last
> days:-)
> > I am a software developer, most time working with c++ and java.
> > Every time I start to dive into smalltalk world (again),
> > even  if all i have done are bugreports or small bugfixes,
> > it impressed me how much more fun it makes.
> >
> Very nice small fixes :-) Thanks a lot for those!
>
> > Looking at smalltalks history I was always deeply impressed about all
> > its development and *inventions*.
> > (And a bit sad, it is not as recognized as it
> > could be, and seeing how others again reinventing these things.)
> >
>
> Yes, and it is important that we move the system forward so we are not
> out-invented
> by the world…
>
> Marcus
>
>
>

Re: [Pharo-dev] Tabs

[S Krish]

It is super cool to see "Chrome"  look n feel in Pharo. More so the startup
of the video..

Way to go Ben.. It is inspiring


On Thu, Jun 20, 2013 at 2:21 PM, Tudor Girba  wrote:

> Great job, Ben.
>
> Doru
>
>
> On Sun, Jun 9, 2013 at 9:03 PM, Benjamin <
> benjamin.vanryseghem.ph...@gmail.com> wrote:
>
>> hello guys :)
>>
>> I would like to introduce a new implementation of tabs with the following
>> features (for now):
>>  - tabs with icon (and a label of course)
>> - un-closable tabs
>> - threaded contents loading (with animated icon)
>>  - shortcuts handling (to navigate from one tab to the next/previous
>> one, to close a tab)
>> - multi-selection (will display all the selected contents with splitter
>> in between)
>>  - actions (each tab can define actions displayed in the tab bar) -
>> Thanks Tudor for the idea
>> - menu items - Thanks Tudor for the idea
>>
>> Here is a little (geeky) video showing a bit of everything:
>> https://dl.dropboxusercontent.com/u/24369478/Tabs.m4v
>>
>> The code can be loaded executing this:
>>
>> Gofer it
>> url: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/Tabs/main';
>>  package: 'ConfigurationOfTabs';
>>  load.
>>
>> ConfigurationOfTabs loadDefault.
>> TabExample open
>>
>> Next steps:
>> - drag and drop (for rearranging tabs)
>>  - Spec support (almost finished)
>>
>>
>> Ben
>>
>>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>

Re: [Pharo-dev] Cairo vs openGL

[S Krish]

+1.

Cairo for 2D and OpenGL for 3D / ( 2D if what Cairo provides is inadequate
for that use case.. )

http://artgrammer.blogspot.in/2011/05/drawing-nearly-perfect-2d-line-segments.html


On Wed, Jun 12, 2013 at 5:45 PM, Clément Bera wrote:

> I asked Igor a few weeks ago. Basically his answers were :
>
> Cairo is for 2D.
> OpenGL is for 3D.
>
> If you do 2D with openGL it is possible but much more complex : a lot of
> API are missing fr 2D rendering.
> Moreover, Cairo is faster for 2D.
>
> Then other guys than me can give other explanations.
>
>
> 2013/6/12 kilon 
>
>> I think its a smart move you started from cairo and then moved to opengl.
>> Its
>> possible afterall to mix cairo with opengl. I think its inevitable . It
>> does
>> not matter that opengl does not specialize on vector graphics, it can do
>> vector graphics and offer massive accelerations in the process.
>>
>> As soon as I learn opengl my focus will be shifted to porting morphic (at
>> least the base part) and drag Athens in the process. So tell your friend
>> that opengl support is definetly coming ;) . Just dont tell him "soon" :D
>>
>> I am not going to be rewriting Cairo into smalltalk of course, or doing
>> any
>> kind of major coding / rewrite , just using the existing methods Cairo has
>> for communicating with opengl. From the little I know it creates a quad
>> polygon in opengl ,apply a texture on it and Cairo is used to draw the
>> texture.
>>
>> One of things people who are not familiar with graphics is general are not
>> aware of is the massive acceleration a GPU can give, that in some cases
>> can
>> outperform CPUs by 100 times. But thats not the mind blowing stuff, the
>> mind
>> blowing stuff is that this acceleration is not even graphics specific.
>> CUDA
>> technology is already used in physics, maths and other extremely demanding
>> computing tasks. Pharo can tap on this massive power (eg . language
>> parsers
>> ) that is even available even on 100 euros nvidia cards and soon will be
>> available for every pc and mac out there for peanuts. Probably its a
>> matter
>> of time before penetrate the mobile market too.
>>
>> We coders in blender (3d app) have already seen blender's new render
>> engine
>> offer the unthinkable , real time full renders with minor delays using the
>> CUDA technology through the new render engine called "cycles". The
>> previous
>> render engine would take at least minutes to offer a same quality render,
>> so
>> its a massive move forward.
>>
>> So my conclusion is that eveything has its place . Cairo + Opengl + CUDA ,
>> makes a trio of ustopable benefits that pharo cannot afford to ignore in
>> any
>> case. I will try to offer my little part in this process, it wont be easy
>> I
>> know , it could take years, but it will certainly be a lot of fun .
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Pharo-dev-Cairo-vs-openGL-tp4692947p4692975.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>
>
> --
> Clément Béra
> Mate Virtual Machine Engineer
> Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
>

Re: [Pharo-dev] SOAP in Pharo

[S Krish]

The approach taken is to simply put the more or less fixed prefix - suffix
Soap Envelope Message to the Document/ Literal XML content.

It is the receiving Server that then does the task of unmarshalling the XML
content and then custom interpreting it for actions..

messageName is the operation to be executed..

http://www.w3.org/2003/05/soap-envelope";>
   
   http://api.ws.liq.misys.com/";>

   - the document literal XML---

   
   




On Wed, Jun 5, 2013 at 10:02 PM, Norbert Hartl  wrote:

>
> Am 05.06.2013 um 15:41 schrieb S Krish  >:
>
> In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach
> and generally works easy and fine.
>
> I would say it is order more easier than what I see Norbert mention,
> unless I miss something in deference to his better experience in Pharo.
>
> Can you elaborate on your explanation? I would like to know how your
> approach works and how it is different to what I do.
>
> With XMLRPC in Pharo I could do a lot  Java - Smalltalk experimentally...
> and I believe it should not be very tough to cobble up the simplest
> workable SOAP interface bi-directional with Document/Literal approach
>
> http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
>
> The namespace complication, which we have avoided/ I would avoid till the
> reasons are high enough to justify.
>
> I'm sorry but I don't understand what you are saying. I think to build any
> generic interface for SOAP you need to parse and generate XML properly
> according to the WSDL spec (I answered Svens email right now explaining
> it).
>
> I would like to see another approach that is simple and smarter than mine.
>
> Norbert
>
> 
>
> Not tested.. but did see this... at some time.. all squeak based..
>
> http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html
>
> http://wiki.squeak.org/squeak/1399.diff?id=29
>
> http://wiki.squeak.org/squeak/1228.diff?id=33
>
> http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html
>
>
>
> On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau  wrote:
>
>> Thanks for all the feedback!
>>
>> The SoapOpera library is using XMLSupport and I think it is a basic
>> generate/parse library for SOAP messages.
>> Given the time constraints and the limited number of soap calls we need
>> to implement, I think we will roughly go for Norbert's approach (using
>> XMLSupport) and see if we can/need to work on the SoapOpera library in the
>> future. Or maybe we make a 'lightweight soap' library... I don't know.
>>
>> Johan
>>
>>
>> On 03 Jun 2013, at 19:31, Sven Van Caekenberghe  wrote:
>>
>> >
>> > On 03 Jun 2013, at 18:08, Norbert Hartl  wrote:
>> >
>> >> In order to use SOAP properly you need a full namespace aware xml
>> parser, a xml schema parser, a WSDL parser plus code generator and the will
>> to abuse HTTP completely .
>> >> Even if you build a perfect tool you'll maybe face the not so perfect
>> responses from the remote side.
>> >
>> > Even using the Java stack with all its tools and frameworks, SOAP is
>> still terrible. Especially if you have to interface with Microsofts' idea
>> of SOAP and web services.
>> >
>> > But Johan implied already that it would not be fun.
>> >
>> > On the other hand, I think that XML Support _is_ namespace aware. So it
>> would not be too hard to actually generate/parse SOAP messages for real.
>> You could get already pretty far with that, IMHO.
>> >
>> > Sven
>> >
>> > PS: In another life I did http://common-lisp.net/project/cl-soap/ - it
>> was never perfect but it kind of worked to talk to Google AdWords.
>> >
>> > --
>> > Sven Van Caekenberghe
>> > http://stfx.eu
>> > Smalltalk is the Red Pill
>> >
>> >
>>
>>
>>
>
>

Re: [Pharo-dev] SOAP in Pharo

[S Krish]

In our works ( VA).. we had the "Document-Literal" SOAP wrapper approach
and generally works easy and fine.

I would say it is order more easier than what I see Norbert mention, unless
I miss something in deference to his better experience in Pharo.

With XMLRPC in Pharo I could do a lot  Java - Smalltalk experimentally...
and I believe it should not be very tough to cobble up the simplest
workable SOAP interface bi-directional with Document/Literal approach

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

The namespace complication, which we have avoided/ I would avoid till the
reasons are high enough to justify.



Not tested.. but did see this... at some time.. all squeak based..

http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/soapCore.html

http://wiki.squeak.org/squeak/1399.diff?id=29

http://wiki.squeak.org/squeak/1228.diff?id=33

http://www.mars.dti.ne.jp/~umejava/smalltalk/soapOpera/index.html



On Wed, Jun 5, 2013 at 6:48 PM, Johan Brichau  wrote:

> Thanks for all the feedback!
>
> The SoapOpera library is using XMLSupport and I think it is a basic
> generate/parse library for SOAP messages.
> Given the time constraints and the limited number of soap calls we need to
> implement, I think we will roughly go for Norbert's approach (using
> XMLSupport) and see if we can/need to work on the SoapOpera library in the
> future. Or maybe we make a 'lightweight soap' library... I don't know.
>
> Johan
>
>
> On 03 Jun 2013, at 19:31, Sven Van Caekenberghe  wrote:
>
> >
> > On 03 Jun 2013, at 18:08, Norbert Hartl  wrote:
> >
> >> In order to use SOAP properly you need a full namespace aware xml
> parser, a xml schema parser, a WSDL parser plus code generator and the will
> to abuse HTTP completely .
> >> Even if you build a perfect tool you'll maybe face the not so perfect
> responses from the remote side.
> >
> > Even using the Java stack with all its tools and frameworks, SOAP is
> still terrible. Especially if you have to interface with Microsofts' idea
> of SOAP and web services.
> >
> > But Johan implied already that it would not be fun.
> >
> > On the other hand, I think that XML Support _is_ namespace aware. So it
> would not be too hard to actually generate/parse SOAP messages for real.
> You could get already pretty far with that, IMHO.
> >
> > Sven
> >
> > PS: In another life I did http://common-lisp.net/project/cl-soap/ - it
> was never perfect but it kind of worked to talk to Google AdWords.
> >
> > --
> > Sven Van Caekenberghe
> > http://stfx.eu
> > Smalltalk is the Red Pill
> >
> >
>
>
>

Re: [Pharo-dev] More signs of growth

[S Krish]

+1 , Yes exact sentiment I stated in a fwd mail to colleagues.. Pharo is
growing and surely converting existing Java programmers to take a deeper
look in.


On Tue, May 28, 2013 at 6:52 PM, Sean P. DeNigris wrote:

> I see users asking questions on the users list who I've never seen before
> :)
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/More-signs-of-growth-tp4690436.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>