Re: [Pharo-users] Where do we go now ?

2018-04-13 Thread Joe Shirk
I've been a lurk-fan for a long time but this brings up something that
distressed me. Richard Eng, Smalltalk Renaissance hero loves to say
Smalltalk's grammar/syntax fits on a postcard.

But the vocabulary doesn't. There is nothing English-like about the always
expanding bewildering   library namespaces.

GT what? Oh a newbie might eventually figure out it means Glamorous
Toolkit. These are meaningless brands. In this drive to come up with
creative names for "just objects" that explain nothing at all, Smalltalk is
becoming like Java or PHP hell.
Just look at those examples through the eyes of a novice. The purity is
nowhere to be found.
:(

On Apr 13, 2018 1:56 AM, "Benoit St-Jean via Pharo-users" <
pharo-users@lists.pharo.org> wrote:



-- Forwarded message --
From: Benoit St-Jean 
To: pharo-users@lists.pharo.org
Cc:
Bcc:
Date: Fri, 13 Apr 2018 05:53:46 + (UTC)
Subject: Where do we go now ?
Hello guys,

Just a quick word to get some things straight because, quite frankly, I
really don't know where we're heading.

When Pharo started, the goal was to depart from Squeak and do a *major
clean up* of all the code, especially Morphic.  The promise of a new, clean
& lean Smalltalk attracted a lot of people.  And then...

I'm looking at the Pharo 7.0 image right now and I just don't get where
we're heading.  Every Pharo release gets bigger, and bigger, and bigger.  I
don't mind the environment getting bigger if it adds functionalities or new
tools but that's not quite the case here. LOTS of stuff is just duplicated.

Do we really need 2 code completion classes (NECController, NOCController)
?  Do we really need 2 system browsers (Nautilus, Calypso)? Do we really
need 2 compilers (OpalCompiler, Compiler) ?  Do we really need 8 delay
schedulers (DelayMicrosecondScheduler, DelayMillisecondScheduler,
DelayNullScheduler, DelayExperimentalSpinScheduler, DelaySpinScheduler,
DelayTicklessScheduler, DelayExperimentalCourageousScheduler,
DelayExperimentalSemaphoreScheduler) ?  Do we really need 2 inspectors
(GTInspector, EyeInspector) ?  Do we really need 2 workspaces
(GTPlayground, Workspace) ? Et cetera. Et cetera. Et cetera.  I could go
on, and on, and on...

Pharo 5.1 had 5885 classes. Pharo 6.1 had 6481 classes. Pharo 7.0 alpha has
7612 classes.  Can you see a trend?

Pharo 5.1 had 416 preference settings. Pharo 6.1 had 494 preference
settings. Pharo 7.0 alpha has 662 preference settings.  Can you see a trend?

Pharo 5.1 had a 27.44 MB image. Pharo 6.1 had a 35.18 MB image. Pharo 7.0
alpha has a 47.97 MB image.  Can you see a trend?

Add to that the fact that Pharo is a nightmare when you want to port code.
Just with the 7.0 release, 61 classes will be deprecated (and lots more to
come if you search for the string "deprecated" into the code, most of the
time hidden in the comments of the soon-to-be-deprecated-in-Pharo-8-I-guess
classes).

You have code that deals with sockets, should you use the old Socket
classes or convert everything to Zodiac? And why do we keep both
"frameworks" in the image ?  Pharo hasn't been backward compatible with
"old socket classes" a looong time ago anyway!

You have code that deals with dependencies, should you use the old
dependents mechanism or convert everything to announcements?

UI speaking, what framework should anyone use ?  Athens?  Something else?

You have code that deals with streams, should you use the old stream
classes or convert everything to Zinc ? And why do we keep both
"frameworks" in the image ?  Pharo hasn't been backward compatible with the
old stream classes a looong time ago anyway!

So what's the plan?  For instance, should I keep using the Nautilus Browser
or I should switch to the Calypso browser and get used to it because
Nautilus will be deprecated?  Or should I just don't care because a third
system browser will be added in Pharo 8 just because "it's cool, let's add
this one too!" ?

Couldn't we just decide on what's "official" and what's a goodie or an
external optional tool/package/framework the same way all other Smalltalks
do?  If you say Calypso is the official & supported browser, fine!  Then
just get Nautilus out of the image, create a nice loadable package for it
and if someone prefers Nautilus, they'll just have to load it into the
image, the same way VW has a gazillion optional tools/packages/frameworks
you can load from a parcel!

Whenever I get asked a simple question by a newbie like "Oh, which system
browser should I use?", quite frankly, I don't know what to answer.  Did we
include Calypso to deprecate Nautilus later?  Is Calypso just a proof of
concept?  Is it just an optional tool?  What about all those delay
schedulers?

"I loaded this code from SqueakSource and it just doesn't work".  Should I
help the guy to fix it or just tell him to convert all the code to the
corresponding framework in Pharo?

Perhaps a little bit of clarity and details about what's coming and what's
the plan would be 

Re: [Pharo-users] line drawing bug

2018-04-06 Thread joe

That worked, thank you so much! This helps me get running in the interim while 
i investigate how to use Athens.


{ jb }

On Apr 6, 2018, 9:31 AM -0400, Nicolai Hess <nicolaih...@gmail.com>, wrote:
> Hi Joe,
>
> the problem is that the BalloonCanvas (or some objects it is using) aren't 
> fully reset after some drawing operations.
> (the drawString method for example sets the sourceForm as glyph to be drawn).
>
> it should work if you do not store the canvas instance, but create a new in 
> every loop:
>
>     points do: [ :p |
>
>    canvas := form getCanvas asBalloonCanvas aaLevel:4; yourself.
>
>    canvas drawPolygon: p
>   color: Color transparent
>   borderWidth: 1
>   borderColor: Color red.
>
>    canvas drawString: p first asString
>   at: p first
>   font: nil
>   color: Color green.
>     ].
>
>
>
>
> Or just reset the engine state (but I don't like this solution, the engine 
> state should be private to the canvas).
>
>     points do: [ :p |
>
>    canvas drawPolygon: p
>   color: Color transparent
>   borderWidth: 1
>   borderColor: Color red.
>
>    canvas drawString: p first asString
>   at: p first
>   font: nil
>   color: Color green.
>    canvas resetEngine.
>     ].
>
>
>
>
>
> > 2018-04-06 2:57 GMT+02:00 <j...@boremaj.net>:
> > > Hello everyone!
> > >
> > > Im trying use the balloon canvas to draw some nice smooth anti aliased 
> > > lines, but now i seem to have hit upon a bug which i dont know how to fix.
> > >
> > > if i draw just lines i get everything i want.  but if i add a 
> > > “drawString:…” in there at any point, all the lines i try to draw 
> > > subsequently dont show up.
> > >
> > > Here is code that shows the exact issue:
> > >
> > > > form := Form extent: 100@100 depth: 32.
> > > > form fillWhite.
> > > > canvas := BalloonCanvas on: form.
> > > > canvas aaLevel: 4.
> > > > "canvas := FormCanvas on: form."
> > > > points := { {10@10 . 50@43} . {50@42 . 90@75} . {90@75 . 50@90 } }.
> > > >
> > > > points do: [ :p |
> > > >    canvas drawPolygon: p
> > > >       color: Color transparent
> > > >       borderWidth: 1
> > > >       borderColor: Color red.
> > > >
> > > >    canvas drawString: p first asString
> > > >       at: p first
> > > >       font: nil
> > > >       color: Color green.
> > > > ].
> > > >
> > > > morph := ImageMorph new.
> > > > morph image: form.
> > > > morph openCenteredInWorld.
> > >
> > >
> > > if i comment out the canvas drawstring i get what you would expect: a 
> > > squiggly line.
> > >
> > > if i add in the drawstring, the first line shows up but all the 
> > > subsequent lines do not get drawn.  (both images attached)
> > >
> > > I spent a bunch of time tracking it down to its most purest form and then 
> > > a bunch of time debugging it and im out of my depth with the baloon code, 
> > > i cant seem to figure out whats wrong.  if anyone knows whats wrong or 
> > > can give me a clue on how to fix it i’d greatly appreciate it.
> > >
> > > thanks in advance.
> > >
> > >
> > > { jb }
>


Re: [Pharo-users] line drawing bug

2018-04-06 Thread joe


No at least not right now.


{ jb }

On Apr 6, 2018, 8:11 AM -0400, Hilaire , wrote:
> Does { jb } want to deploy on tablet computer (Android or iOS) ?
>
>
> Le 06/04/2018 à 12:31, Esteban Lorenzano a écrit :
> > real question is why you use Balloon and not Athens:)
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>


Re: [Pharo-users] line drawing bug

2018-04-06 Thread joe

I must have missed the deprecation warnings when i ran my code. 8).

Ill check out Athens, i don’t want to have to rewrite the entire application to 
support a new drawing backend. As a first step it would be great if i could 
render to an Athens canvas using the same API or something like it, but in my 
quick experiments I’ve had no luck. I’m sure I’m doing something wrong.

Is there any Athens tutorial documentation? All I’ve found is forum posts and 
videos and most of that stuff is quite old and there are a lot of broken links.


{ jb }

On Apr 6, 2018, 6:32 AM -0400, Esteban Lorenzano , wrote:
> hi,
>
> real question is why you use Balloon and not Athens :)
>
> cheers,
> Esteban
>


[Pharo-users] line drawing bug

2018-04-05 Thread joe
Hello everyone!

Im trying use the balloon canvas to draw some nice smooth anti aliased lines, 
but now i seem to have hit upon a bug which i dont know how to fix.

if i draw just lines i get everything i want.  but if i add a “drawString:…” in 
there at any point, all the lines i try to draw subsequently dont show up.

Here is code that shows the exact issue:

> form := Form extent: 100@100 depth: 32.
> form fillWhite.
> canvas := BalloonCanvas on: form.
> canvas aaLevel: 4.
> "canvas := FormCanvas on: form."
> points := { {10@10 . 50@43} . {50@42 . 90@75} . {90@75 . 50@90 } }.
>
> points do: [ :p |
>    canvas drawPolygon: p
>       color: Color transparent
>       borderWidth: 1
>       borderColor: Color red.
>
>    canvas drawString: p first asString
>       at: p first
>       font: nil
>       color: Color green.
> ].
>
> morph := ImageMorph new.
> morph image: form.
> morph openCenteredInWorld.


if i comment out the canvas drawstring i get what you would expect: a squiggly 
line.

if i add in the drawstring, the first line shows up but all the subsequent 
lines do not get drawn.  (both images attached)

I spent a bunch of time tracking it down to its most purest form and then a 
bunch of time debugging it and im out of my depth with the baloon code, i cant 
seem to figure out whats wrong.  if anyone knows whats wrong or can give me a 
clue on how to fix it i’d greatly appreciate it.

thanks in advance.


{ jb }


Re: [Pharo-users] PharoJS Killer app

2017-07-01 Thread Joe Shirk
I think PharoJS can, and should do this much better: https://blockstack.org

On Wed, Jun 28, 2017 at 11:21 PM, askoh  wrote:

> Norbert:
>
> Great answer. Spoken like a wise man.
>
> I want a web app to fill paper forms - like income tax forms say. The forms
> are scanned or input into the app. The developer provides the logic
> connecting the input and output fields of the forms. The users then use the
> app to fill their own forms, print them or send them electronically. Can
> Smalltalk provide a superior solution? How?
>
> Thanks,
> Aik-Siong
>
>
>
> --
> View this message in context: http://forum.world.st/Re-
> PharoJS-tp4952267p4952833.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


-- 
Gmail is unsecure. See: EFF Surveillance Self-Defense Project


If you wish to discuss private or sensitive concerns, I suggest using my
preferred secure email address: godparti...@protonmail.ch or, if you prefer
to send to this gmail account, consider using https://www.mailpile.is and
using encryption with my Public Key:
https://pgp.mit.edu/pks/lookup?op=vindex=0x8726E59217F0E6F9


Re: [Pharo-users] real world pharo web application set ups

2016-12-13 Thread Joe Shirk
Here is one I am really impressed with; I can't say just how much of it is
Pharo:

https://medium.com/concerning-pharo/pharo-beta-nine-59ee972d321a

On Tue, Dec 13, 2016 at 12:00 PM, 
wrote:

> --
>
> Message: 1
> Date: Mon, 12 Dec 2016 19:16:26 +0100
> From: Volkert 
> To: Any question about pharo is welcome 
> Subject: [Pharo-users] real world pharo web application set ups
> Message-ID: <7b7e6144-724f-1eb7-8033-8cfe87a34...@nivoba.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> After reading reading "Enterprise Pharo a Web perspective", i am curious
> to learn more about current real world pharo web application set ups.
> any case studies or blue prints around? i am interested in application
> domain, system architecture, infrastructure (HW/OS/DB),  performance
> goals (concurrent users, transactions, ...), system sizing, scalability
> strategies, 
>
> everything which could important to convince "me" to select pharo as a
> platform for a saas solution ...
>
> Thanks,
> Volkert
>
>
>
>
>


Re: [Pharo-users] PharoJVM

2015-12-14 Thread Joe Shirk
what about haxe crosscompile language?