Re: [Pharo-users] Teapot and SSL

[Sven Van Caekenberghe]

> On 20 Dec 2018, at 22:09, horrido  wrote:
> 
> I had this working some many months ago, but now I can't get it to work.
> Really annoying. The entire process is so arcane...
> 
> My HTTP server starts like this:
> 
> Teapot stopAll.
> Teapot on
>   Get: blah blah blah
> 
> Then I visit http://localhost:1701/.
> 
> I created a self-signed cert called newcert.pem. My HTTPS server starts like
> this:
> 
> Teapot stopAll.
> secureServer := (ZnSecureServer on: 1443)
>   certificate: '/home/richard/newcert.pem';
>   logToTranscript;
>   start;
>   yourself.
> teapot := Teapot configure: { #znServer -> secureServer }.
> teapot
>   Get: blah blah blah
> 
> When I visit https://localhost/, I get "Unable to connect". I tried
> localhost:1701, localhost:1443, just about every damn port number I can
> think of. No joy.
> 
> So what the devil am I doing wrong???

First, this only works for Linux (as far as I know, have experienced, others 
have reported differently).

Second, a self-signed certificate is considered insecure (more so nowadays), so 
you will have to force your browser to continue through lots of scary warnings.

I just tried in Ubuntu 18.04.O1 LTS 64-bit, using Pharo 7 and FireFox, and it 
worked.

As an aside, I would not do stuff like this, SSL is no joke, it is serious 
business: a certificate means something for real. This is not something you 
slam on for fun in a demo. In production systems, it is much better to put 
nginx or something like that in front of your app to add high quality ssl (with 
infinitely more documentation, options, users, experience, etc ...), but even 
there a quick and dirty self signed certificate won't get you very far.

Sven 

Re: [Pharo-users] Teapot and SSL

[Sven Van Caekenberghe]

> On 21 Dec 2018, at 12:00, Sven Van Caekenberghe  wrote:
> 
> I just tried in Ubuntu 18.04.O1 LTS 64-bit, using Pharo 7 and FireFox, and it 
> worked.

BTW, I made my certificate like this (on macOS):

prometheus:tmp sven$ mkdir ssl
prometheus:tmp sven$ cd ssl
prometheus:ssl sven$ openssl genrsa -out privkey.pem 1024
Generating RSA private key, 1024 bit long modulus
..++
..++
e is 65537 (0x10001)
prometheus:ssl sven$ openssl req -new -key privkey.pem -out certreq.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-
Country Name (2 letter code) []:BE
State or Province Name (full name) []:
Locality Name (eg, city) []:Hasselt
Organization Name (eg, company) []:Beta Nine
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:Sven Van Caekenberghe
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
prometheus:ssl sven$ openssl x509 -req -days 3650 -in certreq.csr -signkey 
privkey.pem -out newcert.pem
Signature ok
subject=/C=BE/L=Hasselt/O=Beta Nine/CN=Sven Van Caekenberghe
Getting Private key
prometheus:ssl sven$ ( openssl x509 -in newcert.pem; cat privkey.pem ) > 
server.pem
prometheus:ssl sven$ ls
certreq.csr newcert.pem privkey.pem server.pem
prometheus:ssl sven$ ls -la server.pem 
-rw-r--r--  1 sven  staff  1681 Dec 21 11:28 server.pem
prometheus:ssl sven$ pwd
/Users/sven/tmp/ssl
prometheus:ssl sven$ 
Display all 2771 possibilities? (y or n)
prometheus:ssl sven$ ls
certreq.csr newcert.pem privkey.pem server.pem

[Pharo-users] PetitParser release: v2.1.0

[Julien]

Hello,

This email to announce that a new minor release of PetitParser (1) has been 
published on GitHub (v2.1.0).

Here is the change log:

Summary
---
- Each package has its tests separated in a separated package.
- Cleaned baseline, made it more modular.
- Created more groups to let people load the part of the project they want.
- Some cleaning in `PetitParser` package.
- Integrated PetitPreprocessor and PetitParserExtensions in the project as 
separated groups

Changelog
---
#31 Extract PPTextHighlighter into a separated package.
#21 Add contribution guidelines
#13 Update README with new groups
#9 Fix CI configuration
#19 A TODO comment in PPMemoizedParser>>#parseOn: might need to be fixed 
cleaning
#11 Inconsistent method classification
#15 Split tests in their own packages cleaning
#22 PetitPreprocessor is missing some extensions
#3  Use `>>>` notation for examples inside method
#8 PPStream>>#column: has commented code that should be removed
#7  PPCharSetPredicate and PPContextMemento need to be commented
#1  Replace 'Oops' error message with a meaningful message
#4 PPContext>>#on:stream: should be removed
#2 Integrate PetitParserExtensions package from Smalltalkhub
#5 Integrate PetitPreprocessor package from Smalltalkhub

Thanks to Cyril Ferlicot for his help.

Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

Hi,

Thanks for detailing your thoughts.

Indeed, I know about your application. Whatever you can do with the current GT 
you will be able to do with the new one.

Except that for the new one you will be able to do extra things. Here are a few:
- You can build and share documents that embed those inspector views. This can 
be useful for reporting or sharing diagnostics with your users.
- Because the underlying rendering engine is much more powerful, you can 
express modern and interfaces that integrate with the rest of the environment 
smoothly.
- You likely have to deal with log files that might get large. First, the new 
editor allows you to smoothly work with such files. But, you can go well beyond 
this. Imagine that you build a tooling that produces the same editor only the 
text is interactive, and you might even embed visual artifacts right in the 
text to bridge the gap between what you would see in a typical console. For 
example, this tweet shows the new Transcript used to debug an animation. For 
every animation frame, we output the text corresponding with the frame and we 
insert the graphical preview corresponding to that step.

You look at GT from the point of view of an end-user. You likely like the fact 
that you could mold the environment to your context and that you could do this 
incrementally. It happens that the same principles and tools can be applied to 
the whole programming, and once you do that, you actually can fundamentally 
change the act of programming. In fact, the same thing applies to the old GT: 
we built the new GT using that version and we believe that this allowed us to 
work much faster than if we would have used more traditional tools. The new GT 
pushes the envelope significantly further.

So, that is why we are excited about that perspective, but even if you do not 
spend much time programming in Pharo, you can still take advantage for the user 
point of view as described above :).

Is this answer better?

Cheers,
Doru



> On Dec 21, 2018, at 4:59 PM, Luke Gorrie  wrote:
> 
> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
> The goal of the new GT is to propose a completely reshaped programming 
> experience that enables moldable development. You will find the concepts from 
> the old GT in the new world as well. For example, the Inspector is extensible 
> in similar ways and the API is similar as well.
> [...] 
> Does this address the concern?
> 
> I am not sure yet :).
> 
> Programming is not our main use case for GT. We are using GT as an object 
> inspector (etc) for examining diagnostic data. We have a Smalltalk 
> application that's similar to GDB and we are using GT as the front-end.
> 
> In our world we use the Inspector and the Spotter but all of the Smalltalk 
> programming views are hidden. GT is "molded" to be a diagnostic tool *instead 
> of* a programming environment. Specifically, our main use case is 
> inspecting/debugging the operation of a JIT compiler written in C. We have 
> Smalltalk code to load binary coredumps from the JIT, decode them using DWARF 
> debug information, and represent the application-level compiler data 
> structures as Smalltalk objects. This way we can use GT to browse generated 
> code, cross-reference profiler data, examine runtime compilation errors, etc. 
> 
> The "old" GT is awesome for this. I feel like this application is also very 
> much in the spirit of the "moldable tools" thesis. Lots of diagnostic 
> workflows ultimately boil down to drill-down inspecting and/or searching.
> 
> I don't know where we stand with respect to the "new" GT though. I am talking 
> about diagnostics, you are talking about programming. I am talking about 
> zeros and ones, you are talking about feelings. I am maintaining a stable 
> application, you are talking about rewrites. I am having a hard time whether 
> I should be switching to the new GT in the immediate future, or waiting 
> another year or two for it to mature, or planning to stick with the old GT.
> 
> Hints would be appreciated :)
> 
> I reiterate that I think you guys are doing fantastic work - some of the most 
> interesting work in the programming universe to my mind. I hope that this 
> discussion is useful for at least understanding the thought process of some 
> users / potential users.
> 
> Cheers!
> -Luke
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-users] Teapot and SSL

[horrido]

Okay, I will dispense with the self-signed certificate and purchase a
commercial one, say, from Comodo (PositiveSSL).

I presume once I get it, the code below will work correctly (?). If not,
I'll be back. 


Sven Van Caekenberghe-2 wrote
>> On 20 Dec 2018, at 22:09, horrido <

> horrido.hobbies@

> > wrote:
>> 
>> I had this working some many months ago, but now I can't get it to work.
>> Really annoying. The entire process is so arcane...
>> 
>> My HTTP server starts like this:
>> 
>> Teapot stopAll.
>> Teapot on
>>   Get: blah blah blah
>> 
>> Then I visit http://localhost:1701/.
>> 
>> I created a self-signed cert called newcert.pem. My HTTPS server starts
>> like
>> this:
>> 
>> Teapot stopAll.
>> secureServer := (ZnSecureServer on: 1443)
>>   certificate: '/home/richard/newcert.pem';
>>   logToTranscript;
>>   start;
>>   yourself.
>> teapot := Teapot configure: { #znServer -> secureServer }.
>> teapot
>>   Get: blah blah blah
>> 
>> When I visit https://localhost/, I get "Unable to connect". I tried
>> localhost:1701, localhost:1443, just about every damn port number I can
>> think of. No joy.
>> 
>> So what the devil am I doing wrong???
> 
> First, this only works for Linux (as far as I know, have experienced,
> others have reported differently).
> 
> Second, a self-signed certificate is considered insecure (more so
> nowadays), so you will have to force your browser to continue through lots
> of scary warnings.
> 
> I just tried in Ubuntu 18.04.O1 LTS 64-bit, using Pharo 7 and FireFox, and
> it worked.
> 
> As an aside, I would not do stuff like this, SSL is no joke, it is serious
> business: a certificate means something for real. This is not something
> you slam on for fun in a demo. In production systems, it is much better to
> put nginx or something like that in front of your app to add high quality
> ssl (with infinitely more documentation, options, users, experience, etc
> ...), but even there a quick and dirty self signed certificate won't get
> you very far.
> 
> Sven





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Teapot and SSL

[Sven Van Caekenberghe]

> On 21 Dec 2018, at 21:42, horrido  wrote:
> 
> Okay, I will dispense with the self-signed certificate and purchase a
> commercial one, say, from Comodo (PositiveSSL).

But you cannot buy a certificate for localhost, only for a real domain name 
(that you host for real).

> I presume once I get it, the code below will work correctly (?). If not,
> I'll be back.

Linux only, I would say.

If you want to deploy for real, in some form of production, put nginx in front 
of pharo (as a proxy). That will work infinitely better and easier.

> Sven Van Caekenberghe-2 wrote
>>> On 20 Dec 2018, at 22:09, horrido <
> 
>> horrido.hobbies@
> 
>> > wrote:
>>> 
>>> I had this working some many months ago, but now I can't get it to work.
>>> Really annoying. The entire process is so arcane...
>>> 
>>> My HTTP server starts like this:
>>> 
>>> Teapot stopAll.
>>> Teapot on
>>>  Get: blah blah blah
>>> 
>>> Then I visit http://localhost:1701/.
>>> 
>>> I created a self-signed cert called newcert.pem. My HTTPS server starts
>>> like
>>> this:
>>> 
>>> Teapot stopAll.
>>> secureServer := (ZnSecureServer on: 1443)
>>>  certificate: '/home/richard/newcert.pem';
>>>  logToTranscript;
>>>  start;
>>>  yourself.
>>> teapot := Teapot configure: { #znServer -> secureServer }.
>>> teapot
>>>  Get: blah blah blah
>>> 
>>> When I visit https://localhost/, I get "Unable to connect". I tried
>>> localhost:1701, localhost:1443, just about every damn port number I can
>>> think of. No joy.
>>> 
>>> So what the devil am I doing wrong???
>> 
>> First, this only works for Linux (as far as I know, have experienced,
>> others have reported differently).
>> 
>> Second, a self-signed certificate is considered insecure (more so
>> nowadays), so you will have to force your browser to continue through lots
>> of scary warnings.
>> 
>> I just tried in Ubuntu 18.04.O1 LTS 64-bit, using Pharo 7 and FireFox, and
>> it worked.
>> 
>> As an aside, I would not do stuff like this, SSL is no joke, it is serious
>> business: a certificate means something for real. This is not something
>> you slam on for fun in a demo. In production systems, it is much better to
>> put nginx or something like that in front of your app to add high quality
>> ssl (with infinitely more documentation, options, users, experience, etc
>> ...), but even there a quick and dirty self signed certificate won't get
>> you very far.
>> 
>> Sven
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Tudor Girba]

And here is the tweet I was mentioning:
https://twitter.com/feenkcom/status/1075011040373551104?s=21

Cheers,
Doru

--
www.feenk.com

"Every thing has its own flow."

> On 21 Dec 2018, at 21:32, Tudor Girba  wrote:
> 
> Hi,
> 
> Thanks for detailing your thoughts.
> 
> Indeed, I know about your application. Whatever you can do with the current 
> GT you will be able to do with the new one.
> 
> Except that for the new one you will be able to do extra things. Here are a 
> few:
> - You can build and share documents that embed those inspector views. This 
> can be useful for reporting or sharing diagnostics with your users.
> - Because the underlying rendering engine is much more powerful, you can 
> express modern and interfaces that integrate with the rest of the environment 
> smoothly.
> - You likely have to deal with log files that might get large. First, the new 
> editor allows you to smoothly work with such files. But, you can go well 
> beyond this. Imagine that you build a tooling that produces the same editor 
> only the text is interactive, and you might even embed visual artifacts right 
> in the text to bridge the gap between what you would see in a typical 
> console. For example, this tweet shows the new Transcript used to debug an 
> animation. For every animation frame, we output the text corresponding with 
> the frame and we insert the graphical preview corresponding to that step.
> 
> You look at GT from the point of view of an end-user. You likely like the 
> fact that you could mold the environment to your context and that you could 
> do this incrementally. It happens that the same principles and tools can be 
> applied to the whole programming, and once you do that, you actually can 
> fundamentally change the act of programming. In fact, the same thing applies 
> to the old GT: we built the new GT using that version and we believe that 
> this allowed us to work much faster than if we would have used more 
> traditional tools. The new GT pushes the envelope significantly further.
> 
> So, that is why we are excited about that perspective, but even if you do not 
> spend much time programming in Pharo, you can still take advantage for the 
> user point of view as described above :).
> 
> Is this answer better?
> 
> Cheers,
> Doru
> 
> 
> 
>> On Dec 21, 2018, at 4:59 PM, Luke Gorrie  wrote:
>> 
>> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
>> The goal of the new GT is to propose a completely reshaped programming 
>> experience that enables moldable development. You will find the concepts 
>> from the old GT in the new world as well. For example, the Inspector is 
>> extensible in similar ways and the API is similar as well.
>> [...] 
>> Does this address the concern?
>> 
>> I am not sure yet :).
>> 
>> Programming is not our main use case for GT. We are using GT as an object 
>> inspector (etc) for examining diagnostic data. We have a Smalltalk 
>> application that's similar to GDB and we are using GT as the front-end.
>> 
>> In our world we use the Inspector and the Spotter but all of the Smalltalk 
>> programming views are hidden. GT is "molded" to be a diagnostic tool 
>> *instead of* a programming environment. Specifically, our main use case is 
>> inspecting/debugging the operation of a JIT compiler written in C. We have 
>> Smalltalk code to load binary coredumps from the JIT, decode them using 
>> DWARF debug information, and represent the application-level compiler data 
>> structures as Smalltalk objects. This way we can use GT to browse generated 
>> code, cross-reference profiler data, examine runtime compilation errors, 
>> etc. 
>> 
>> The "old" GT is awesome for this. I feel like this application is also very 
>> much in the spirit of the "moldable tools" thesis. Lots of diagnostic 
>> workflows ultimately boil down to drill-down inspecting and/or searching.
>> 
>> I don't know where we stand with respect to the "new" GT though. I am 
>> talking about diagnostics, you are talking about programming. I am talking 
>> about zeros and ones, you are talking about feelings. I am maintaining a 
>> stable application, you are talking about rewrites. I am having a hard time 
>> whether I should be switching to the new GT in the immediate future, or 
>> waiting another year or two for it to mature, or planning to stick with the 
>> old GT.
>> 
>> Hints would be appreciated :)
>> 
>> I reiterate that I think you guys are doing fantastic work - some of the 
>> most interesting work in the programming universe to my mind. I hope that 
>> this discussion is useful for at least understanding the thought process of 
>> some users / potential users.
>> 
>> Cheers!
>> -Luke
>> 
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> 
> --
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Offray Vladimir Luna Cárdenas]

Hi,

I share your feeling of wonder and also concern Luke.

In my case, I used (old) GT tools to prototype Grafoscopio and now that
the PhD thesis is practically done and only dissertation is pending, I
would like to prepare myself to migrate Grafoscopio to Pharo 7,
including bug fixing, stability, improved functionality, Iceberg for
code management (but supporting Fossil instead of Git).

I think that there is a lot of possibilities in the new GT tools and I
like some of them going into interactive documentation (a line I was
trying to explore with Pharo using Grafoscopio). But anytime I tried to
use it I stumble upon a stop:

  * First time was something related with me having some kind of
credential enabled in GitHub to simple use it. I lost a whole
morning just enabling that and reporting it. It was related with
some mozilla library for font redering that didn't work well at the end.
  * Today I tried with the prebuild Linux image and Pharo Launcher, but
I got an error message about inability to determine proper VM and
when I tried installing it from Pharo 7 I got something related with
a MemoryFileWriteStream dependency to be resolved before proper
installation.

I understand that this is alpha software and demos look amazing, but
just running them requires a lot of work that previous GT didn't require.

This brings me this feeling that these jumps in Pharo put core of the
user experience at risk (kind of) and you end wondering how much an old
tech will be maintained once the jump to the new shinny stuff is done
and which is the migration path.

In my case, I would like to have something like a Zeroconf script that
just takes care of the external libraries, VM and image, to have a real
glipmse of the upcoming future, beside the Tweets (which look great
BTW). Maybe it will happen in a year or two, once it is properly
integrated with Pharo, Zeroconf and thought for "end users" of
interactive documents, which don't want to enable GitHub stuff, deal
with external rendering dependencies and so on. Now the experience of
using GT is kind of hostile for that users.

Anyway, keep the good work and sharing it. Hopefully at some point it
will reach the beta status, where users like myself can use it smoothly
and build on GT's promises and interesting features.

Cheers,

Offray

On 21/12/18 10:59, Luke Gorrie wrote:
> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  > wrote:
>
> The goal of the new GT is to propose a completely reshaped
> programming experience that enables moldable development. You will
> find the concepts from the old GT in the new world as well. For
> example, the Inspector is extensible in similar ways and the API
> is similar as well.
>
> [...] 
>
> Does this address the concern?
>
>
> I am not sure yet :).
>
> Programming is not our main use case for GT. We are using GT as an
> object inspector (etc) for examining diagnostic data. We have a
> Smalltalk application that's similar to GDB and we are using GT as the
> front-end.
>
> In our world we use the Inspector and the Spotter but all of the
> Smalltalk programming views are hidden. GT is "molded" to be a
> diagnostic tool *instead of* a programming environment. Specifically,
> our main use case is inspecting/debugging the operation of a JIT
> compiler written in C. We have Smalltalk code to load binary coredumps
> from the JIT, decode them using DWARF debug information, and represent
> the application-level compiler data structures as Smalltalk objects.
> This way we can use GT to browse generated code, cross-reference
> profiler data, examine runtime compilation errors, etc. 
>
> The "old" GT is awesome for this. I feel like this application is also
> very much in the spirit of the "moldable tools" thesis. Lots of
> diagnostic workflows ultimately boil down to drill-down inspecting
> and/or searching.
>
> I don't know where we stand with respect to the "new" GT though. I am
> talking about diagnostics, you are talking about programming. I am
> talking about zeros and ones, you are talking about feelings. I am
> maintaining a stable application, you are talking about rewrites. I am
> having a hard time whether I should be switching to the new GT in the
> immediate future, or waiting another year or two for it to mature, or
> planning to stick with the old GT.
>
> Hints would be appreciated :)
>
> I reiterate that I think you guys are doing fantastic work - some of
> the most interesting work in the programming universe to my mind. I
> hope that this discussion is useful for at least understanding the
> thought process of some users / potential users.
>
> Cheers!
> -Luke
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

Re: [Pharo-users] Teapot and SSL

[Ben Coman]

On Sat, 22 Dec 2018 at 04:42, horrido  wrote:
>
> Okay, I will dispense with the self-signed certificate and purchase a
> commercial one, say, from Comodo (PositiveSSL).

My web host uses "Lets Encrypt"
https://www.dreamhost.com/hosting/ssl-tls-certificates/

I haven't looked into it deeply, but I've had no trouble with it.

cheers -ben

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Tudor Girba]

Hi Offray,

Thanks for describing your concerns.

First, let’s address the technical part. Please go to gtoolkit.com and download 
the 64Bit distribution that includes the image and the VM. We will remove the 
standalone image option from the website until the VM situation gets clarified.

Now, a clarification. The old GT was produced over a period of 4 years by an 
open-source team. The project had its own identity, and in 2014 the core of it 
was first integrated in Pharo. I say the core of it, because the visual part 
and other libraries are not in Pharo today. The full potential is found in 
Moose. In any case, during this process, GT got to be identified with Pharo and 
that was a good thing.

The new GT is a product produced by feenk, a company. Much of the original team 
is still active in the new version, but now we commit to our product in a 
different way. The product is free and open-source, but it’s still a product 
with an identity and a goal. At present time, both the team, identity and goal 
are different than those of Pharo.

Our goal is to offer a fundamentally new alternative to program (including 
comparing to what is possible now in Pharo). We are not looking for marginal 
improvements, and we are not aiming at backward compatibility.

To build this alternative we invested in a whole new stack. That is not a tiny 
challenge and getting it right requires many iterations and feedback. We say we 
are in alpha not because of inconveniences of installation but because we are 
still very much developing the product.

We announced the first alpha version in September and since then much has 
changed. At present time, we did manage to reach a situation where downloading 
the distribution should run on Mac, Linux and Windows. Even so, the current 
version is only for people that do want to try knowing that there will be 
hurdles.

A word about the user experience. The current version runs inside the Pharo UI 
because we need to bootstrap. But, our goal is to build a complete IDE on the 
new stack. If you want to judge the user experience, it is only meaningful to 
do it within the GT windows, and not by comparing it with the rest of the 
existing Pharo UI.

Does this clarify the situation?

Cheers,
Doru

--
www.feenk.com

"Every thing has its own flow."

> On 21 Dec 2018, at 23:02, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> I share your feeling of wonder and also concern Luke.
> 
> In my case, I used (old) GT tools to prototype Grafoscopio and now that the 
> PhD thesis is practically done and only dissertation is pending, I would like 
> to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, 
> stability, improved functionality, Iceberg for code management (but 
> supporting Fossil instead of Git).
> 
> I think that there is a lot of possibilities in the new GT tools and I like 
> some of them going into interactive documentation (a line I was trying to 
> explore with Pharo using Grafoscopio). But anytime I tried to use it I 
> stumble upon a stop:
> 
> First time was something related with me having some kind of credential 
> enabled in GitHub to simple use it. I lost a whole morning just enabling that 
> and reporting it. It was related with some mozilla library for font redering 
> that didn't work well at the end.
> Today I tried with the prebuild Linux image and Pharo Launcher, but I got an 
> error message about inability to determine proper VM and when I tried 
> installing it from Pharo 7 I got something related with a 
> MemoryFileWriteStream dependency to be resolved before proper installation.
> I understand that this is alpha software and demos look amazing, but just 
> running them requires a lot of work that previous GT didn't require. 
> This brings me this feeling that these jumps in Pharo put core of the user 
> experience at risk (kind of) and you end wondering how much an old tech will 
> be maintained once the jump to the new shinny stuff is done and which is the 
> migration path.
> 
> In my case, I would like to have something like a Zeroconf script that just 
> takes care of the external libraries, VM and image, to have a real glipmse of 
> the upcoming future, beside the Tweets (which look great BTW). Maybe it will 
> happen in a year or two, once it is properly integrated with Pharo, Zeroconf 
> and thought for "end users" of interactive documents, which don't want to 
> enable GitHub stuff, deal with external rendering dependencies and so on. Now 
> the experience of using GT is kind of hostile for that users.
> 
> Anyway, keep the good work and sharing it. Hopefully at some point it will 
> reach the beta status, where users like myself can use it smoothly and build 
> on GT's promises and interesting features.
> 
> Cheers,
> 
> Offray
>> On 21/12/18 10:59, Luke Gorrie wrote:
>> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
>>> The goal of the new GT is to propose a completely reshaped programming 
>>> experience that enables molda

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

[Ben Coman]

On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna Cárdenas
 wrote:
>
> Hi,
>
> I share your feeling of wonder and also concern Luke.
>
> In my case, I used (old) GT tools to prototype Grafoscopio and now that the 
> PhD thesis is practically done and only dissertation is pending, I would like 
> to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, 
> stability, improved functionality, Iceberg for code management (but 
> supporting Fossil instead of Git).
>
> I think that there is a lot of possibilities in the new GT tools and I like 
> some of them going into interactive documentation (a line I was trying to 
> explore with Pharo using Grafoscopio). But anytime I tried to use it I 
> stumble upon a stop:
>
> First time was something related with me having some kind of credential 
> enabled in GitHub to simple use it. I lost a whole morning just enabling that 
> and reporting it.

Was this on Windows? What was the fix for worked for you? (sorry its
easier to ask again than try to identify in the archives a previous
mention)

cheers -ben

> It was related with some mozilla library for font redering that didn't work 
> well at the end.

> Today I tried with the prebuild Linux image and Pharo Launcher, but I got an 
> error message about inability to determine proper VM and when I tried 
> installing it from Pharo 7 I got something related with a 
> MemoryFileWriteStream dependency to be resolved before proper installation.
>
> I understand that this is alpha software and demos look amazing, but just 
> running them requires a lot of work that previous GT didn't require.
>
> This brings me this feeling that these jumps in Pharo put core of the user 
> experience at risk (kind of) and you end wondering how much an old tech will 
> be maintained once the jump to the new shinny stuff is done and which is the 
> migration path.
>
> In my case, I would like to have something like a Zeroconf script that just 
> takes care of the external libraries, VM and image, to have a real glipmse of 
> the upcoming future, beside the Tweets (which look great BTW). Maybe it will 
> happen in a year or two, once it is properly integrated with Pharo, Zeroconf 
> and thought for "end users" of interactive documents, which don't want to 
> enable GitHub stuff, deal with external rendering dependencies and so on. Now 
> the experience of using GT is kind of hostile for that users.
>
> Anyway, keep the good work and sharing it. Hopefully at some point it will 
> reach the beta status, where users like myself can use it smoothly and build 
> on GT's promises and interesting features.
>
> Cheers,
>
> Offray
>
> On 21/12/18 10:59, Luke Gorrie wrote:
>
> On Thu, 20 Dec 2018 at 10:58, Tudor Girba  wrote:
>>
>> The goal of the new GT is to propose a completely reshaped programming 
>> experience that enables moldable development. You will find the concepts 
>> from the old GT in the new world as well. For example, the Inspector is 
>> extensible in similar ways and the API is similar as well.
>
> [...]
>>
>> Does this address the concern?
>
>
> I am not sure yet :).
>
> Programming is not our main use case for GT. We are using GT as an object 
> inspector (etc) for examining diagnostic data. We have a Smalltalk 
> application that's similar to GDB and we are using GT as the front-end.
>
> In our world we use the Inspector and the Spotter but all of the Smalltalk 
> programming views are hidden. GT is "molded" to be a diagnostic tool *instead 
> of* a programming environment. Specifically, our main use case is 
> inspecting/debugging the operation of a JIT compiler written in C. We have 
> Smalltalk code to load binary coredumps from the JIT, decode them using DWARF 
> debug information, and represent the application-level compiler data 
> structures as Smalltalk objects. This way we can use GT to browse generated 
> code, cross-reference profiler data, examine runtime compilation errors, etc.
>
> The "old" GT is awesome for this. I feel like this application is also very 
> much in the spirit of the "moldable tools" thesis. Lots of diagnostic 
> workflows ultimately boil down to drill-down inspecting and/or searching.
>
> I don't know where we stand with respect to the "new" GT though. I am talking 
> about diagnostics, you are talking about programming. I am talking about 
> zeros and ones, you are talking about feelings. I am maintaining a stable 
> application, you are talking about rewrites. I am having a hard time whether 
> I should be switching to the new GT in the immediate future, or waiting 
> another year or two for it to mature, or planning to stick with the old GT.
>
> Hints would be appreciated :)
>
> I reiterate that I think you guys are doing fantastic work - some of the most 
> interesting work in the programming universe to my mind. I hope that this 
> discussion is useful for at least understanding the thought process of some 
> users / potential users.
>
> Cheers!
> -Luke
>
>
>
> __

Re: [Pharo-users] Teapot and SSL

[Pierce Ng]

On Fri, Dec 21, 2018 at 02:42:04PM -0600, horrido wrote:
> Okay, I will dispense with the self-signed certificate and purchase a
> commercial one, say, from Comodo (PositiveSSL).

Use Let's Encrypt-issued certificates, available without charge. Let's
Encrypt's CA certificate is built-in trusted by all the major web
browsers, meaning no action is required on the part of the web browser
user when visiting a site over HTTPS with certificate issued by Let's
Encrypt.

Use Caddy as reverse proxy for your webapp. Caddy has transparent
integration with Let's Encrypt: it generates/saves crypto keys, performs
the Let's Encrypt protocol dances to request for and renew Let's Encrypt
certificates, meaning no action is required on the part of the web
site/app administrator after setting it up.

Use Docker, which makes it easy to set up Caddy and your Pharo webapp. 

See my recent blog post:

  https://www.samadhiweb.com/blog/2018.12.09.https.html

Pierce