Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Hi Ben
Maybe you misunderstood what I meant.
I was thinking of Pharo-backward-compatibility.
not Smalltalk-backward-compatibility

I am only suggesting that Pharo should be downward compatible
(that is, within Pharo's scope only). 
meaning that everything built wit Pharo version X  
should load and run in Pharo pharo version X + n
without any changes. 

This means that a package/app running OK in Pharo 8,
should work without any changes whatsoever
in, say, Pharo 12, ca 2 years later. and even beyond that,
preferably many Pharo releases later!

Therefore, any extension/improvement of Pharo itself should be done
on top of that, not by replacing/deprecating existing classes.
As not to break downward compatibility.

(looking at the basic underlying system classes, it looks
like this has already been done that way in most cases, 
simply because Smalltalk is a hierarchical rooted object system, 
which means that changing the deeper is very hard because
it (could) tears up the very fabric of Smalltalk/Pharo itself,
right?)


If one reads through this Pharo user forum, and also many other 
Smalltalk forums, you can read about many cases of packages that 
no longer will work after yet another version of Pharo is released. 
This is unacceptable: new Pharo releases should not break those
packages.

read again:
> Downward compatibility prevents people 
> from have tediously edit and test their packages 
> again and again each time some have 
> the "brilliant" idea to deprecate stuff. 

Let's assume for a moment that I want (currently i don't) 
to create a package/application, taking many months of my precious time. 
After a long time, my hard work is finally completed and tested: wow, the 
big dragon flies! 

However, yet another year later, it no longer loads and I have to spend a 
considerable amount of time re-editing and testing my package to get 
it working correctly again, let alone thereby considering the delicate
interaction 
with other third party packages that -guess what?- 
are dealing with similar release breaking problems at the same time.

Unnecessary work, repeating itself with almost every new version of Pharo.

Realizing that this is an almost eternal trap, this suffices to deter me
from even 
starting to create such a package! Thus trying to avoid a very tedious 
and iterating process of repairing things that once were perfectly OK. 

Somehow many don't seem get this:
Too academic? making some sort of hobby out of their work.
without realizing real-world situations in a though production/industrial 
environment. In combination with the lack of standardization of Smalltalk, 
this is probably one  the reasons the installed base of Smalltalk 
(and Pharo based apps) is very small.

If one doesn't understand this, one should ask themselves why the heck
they are software developers in the first place. 

On IBM mainframes I can still load and recompile unchanged COBOL source
files
from ca. 1974 and they'll run flawlessly: more than 40 years later.
(btw your bank account runs on mainframes, probably in COBOL btw.)

Of course it is a splendid idea to improve Pharo,
seeing how Pharo is now, great to work with. 
However, this should be done in such a way that 
downward compatibility is guaranteed.



IMHO, Regards
TedvG.







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

Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Although I'll stick to what I wrote,
looking back at what I wrote, it appears as to be
not friendly at all times, I will try to prevent that next time.
It also has to do with communication in writing only, which
is a whole lot different as talking and listening while e.g.
sharing a table together and discuss things e.g. during a coffee break..
and some laughter at times.

What I still kindly suggest:
make improvement/changes only in such
a way that anything written before will
run without any modification, which in fact
also means: do not deprecate things!

Downward compatibility prevents people
from have tediously edit and test their packages
again and again each time some have
the "brilliant" idea to deprecate stuff.
This is probably the biggest curse in 
software development these days. 


If you want to implement newer core like things
co-existence with previous is preferable.
Do at the very least not alter the core/system classes.

It is probably also the maximum level where
standardization in Smalltalk is possible, nevertheless..
This attitude then could open up the possibility for minimal
standardization for core/system classes. Solely on that level. 
On top of that everybody can build whatever they want.

In any aspect in industry the awareness that standardization
is a necessity is beyond any doubt, alas, not in software
development. One of the reasons aeroplanes are falling
from the sky, elections go wrong and so on.

For those not aware about the importance of standardization:
read this: 
https://en.wikipedia.org/wiki/Standardization

 

Regards
TedvG












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

Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Although I'll stick to what I wrote,
looking back at what I wrote, it appears as to be
not friendly at all times, I will try to prevent that next time.
It also has to do with communication in writing only, which
is a whole lot different as talking and listening while e.g.
sharing a table together and discuss things e.g. during a coffee break..
and some laughter at times.

What I still kindly suggest:
make improvement/changes only in such
a way that anything written before will
run without any modification, which in fact
also means: do not deprecate things!

Downward compatibility prevents people
from have tediously edit and test their packages
again and again each time some have
the "brilliant" idea to deprecate stuff.
This is probably the biggest curse in 
software development these days. 


If you want to implement newer core like things
co-existence with previous is preferable.
Do at the very least not alter the core/system classes.

It is probably also the maximum level where
standardization in Smalltalk is possible, nevertheless..
This attitude then could open up the possibility for minimal
standardization for core/system classes. Solely on that level. 
On top of that everybody can build whatever they want.

In any aspect in industry the awareness that standardization
is a necessity is beyond any doubt, alas, not in software
development. One of the reasons aeroplanes are falling
from the sky, elections go wrong and so on.

For those not aware about the importance of standardization:
read this: 
https://en.wikipedia.org/wiki/Standardization

 

Regards
TedvG












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

Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Dear Esteban, 
To make a long thread short:

For users, your attitude/opinion  implies the following facts:

-if adhering to Pharo, then all the things one creates become
increasingly incompatible with Smalltalk, because, in effect,
you state that Pharo abandons/deviates from Smalltalk as a standard.
So: 
-If a user wants to be productive:
Why then should they write applications in a Pharo if one looses
the compatibility with the rest of the Smalltalk world? 
(this is actually the REAL subject of this thread, not whether
or not "dissonant" opinions causes list "pollution" imho)

Btw, I am not exactly an "evangelist" with my ca. 2 or 3 
"contributions" to this forum per year, 
so I am not exactly flooding the list, am I?

(btw, most of my reactions to this list were about a 5 year old 
freeze-on-mac-at-full-screen-bug-since-Pharo-5.0
which still hasn't been repaired (VM problem i think))

However, I think this discussion is very important on a user level.
which highly influences whether or not to use Pharo as a real
tool for application development in a production environment
or to regard it as some sort of academic hobby, standing on its own?

But, don't worry, If you'd like to live on an island,
you're free to do so. 
Also of course you are free to completely
ignore and not having some initiative to at least try to
standardize Smalltalk, which would benefit all of us! (user perspective)
The latter btw goes for all Smalltalk incarnations alike, not only Pharo.

Perfect example how to more or less doom a fantastic programming
language/environment
nowhere nothing found alike, by not talking, working together and reaching a
consensus.
(no matter how hard this can be at times, the smaller the islands become) 

Currently I won't recommend Pharo any further to new Smalltalk
users because it puts them, without most of them realizing it, on an
island with no boats to get them back to the real world. 
Never mind, just ignore me, as I am just a mere speck in the 
IT/Smalltalk world and of little significance 

  
I will now forget this whole thing, take a sunny
walk along the Dordogne here, which, if it could talk,
undoubtedly will confirm my question: 
"Pardon me, Dordogne, for asking: Are you a river? " 
with: 
"Huh? Yes of course I am, and indeed a beautiful one too, if I may say so!
can't you see that?"

The river is a lot wiser that me: it's only talk
is the serene sound of eternal water flowing by
and the wind playing with the leaves of trees surrounding it.
I could learn a thing or two from that.. so can you.. 

Don't worry I will not react further on this.
eat your own cake, I don't mind.

Regards
TedvG.





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

Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Yes, Esteban, 

maybe I was a bit harsh, in a sense you're right too,
However it becomes blurred then wat Smalltalk really is.
(e.g. I recommend Pharo as Smalltalk to others) 

I would prefer -but who am I- 
that all Smalltalk dialects should implement 
the ANSI standard as a minimum and at least on 
that level stay compatible.
New developments should be built on top of that.
and get incorporated in the ANSI standard at certain points in time.
So that everybody on this planet can work with one Smalltalk.
That makes sense, don't you agree? 

They came very close to that with PLs like COBOL, ANSI C etc. 

Standardization is industrial. No need
to further explain this I guess. 

The f. devil lives in the details, as they say,
and it is exactly those little differences
that makes it very hard to port packages
from one Smalltalk dialect to another.

In the current situation, that is where everybody wants to 
go their own unique way, this has the consequence that
if one Smalltalk dialect disappears (e.g. Squeak, Pharo, 
Visualworks, whatever)  this would render packages 
with often tons of work(e.g. Roassal ?) 
worthless because they don't load/work in other Smalltalk 
implementations/dialects without rewriting and retesting 
the package again. This should not be the case. 

Again, I am impressed by Pharo and really like it.
but for me it goes too far to say that Pharo isn't Smalltalk.

As a user, I edit classes methods etc in exactly the same
way (syntax) as in most other Smalltalk dialects. 
If you would take out the Smalltalk from Pharo all is left
are a few bolts and nuts rendered useless: nothing
to mount it on.  

(Still the differences are currently not that big: 
if I can file in st files from Squeak from 2010 and the 
only thing I had to change was a datetime property) 
(yet another reason I don't use traits is to remain compatible
as much as possible between different Smalltalk implementations)

my 4 cents. :o)
Regards, thank you.
TedvG
btw
Hard to convince people about this: 
Also. nothing should be deprecated.
Old sources should remain compatible.
(Not like in Swift, where I had to rewrite parts of my 
apps nearly every year because of deprecation fever)

 

 



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

Re: [Pharo-users] About "it's not pharo but smalltalk"

[TedVanGaalen]

Pharo IS Smalltalk, whether you like it or not.
my 2 cents:

This thread is incredibly ridiculous IMHO. 
Is this becoming something like a religious argument, 
like church schisms in medieval times?

Pharo IS Smalltalk and that is good: 
That means everyone that is familiar with
Smalltalk can use Pharo without any serious difficulties.

For example, for learning, one can still use nearly everything 
from an "old" book like "Smalltalk By Example" by Alex Sharp 
from 1997 without any modifications whatsoever.
It all works.

I've ported .st files between different Smalltalk systems
and it nearly always works without any modifications!

(i don't use traits btw, because this is not Smalltalk
as I know it and creates nasty inter-object dependencies,
kind of "goto to attempt to multiple inheritance", but that's me :o)
 
Apart from some minor deviations, Pharo conforms to 
nearly all Smalltalk rules, object hierarchy and syntax.

The fundamental system classes throughout all Smalltalk implementations
are virtually the same everywhere. Thank the gods for that. 
COMPATIBILITY. <- read this again if you like.


Pharo excels in that the Pharo people did a lot of work in making
the Pharo environment productive and a real pleasure to work with!
but under the hood -even with the inclusion of new additions- it luckily
still is Smalltalk.
How can it be not: even the newer Pharo additions are in fact.. classes
written in Smalltalk?

Making too much distinctions and differences between various implementations
and dialects of Smalltalk is not a good idea I think. You all want to 
promote Smalltalk? Then Stick Together As Smalltalkers no matter
what version or dialect one is using!
Does this sound alien to you, maybe? 

To, me personally, it doesn't make much difference because luckily most
Smalltalk
implementations are mostly quite similar, allowing me to switch if needed
between (in arbitrary order , sigh) Squeak, Pharo, VisualWorks etc.
without too much effort.

In making too much distinctions, you are in fact dividing
the Smalltalk community, which is bad in Smalltalk's fragile world.
Smalltalk, indeed, OOP already has too much opposition
of those sticking to other programming techniques etc. 

Kind Regards
TedvG






   




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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Thanks for Pharo 8.0!

Sorry to revive this thread again and again since version 6, 
but the full screen freeze problem on Mac still persists.

Did a clean install today of Pharo 8.0 as follows:
Remove all Pharo, apps, images, launcher from before < Pharo 8.0
(saved my stuff in .st files before doing so)

Installed Pharo 8.0 launcher
-started with vanilla 8.0 64 bit image. 
-changed fonts to medium (4k screen here) 
-saved the image.
-clicked on full screen option in the top menu.
Freezes again in full screen modus. 

As long as I don't go full screen or resize to that,
everything works ok.
Regards
TedvG








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

Re: [Pharo-users] Code of Conduct

[TedVanGaalen]

Couldn't resist entering this doubtful CoC thread, 
just to enter a few lines and then I am gone again.

One doesn't need a Code of Conduct. It is ridiculous.

Civilized and respectful non discriminating behaviour should
be implicit in everyone of us!

If one insists in having a code of conduct than this should cover it all:
"Be Nice, Social And Respectful To Each Living Being."
(at times this is not easy) 

If this is too complicated for one to understand and not enough
to stay on the right track, then know that there already 
are "CoC"s on an encompassing higher scope: by constitutional law:

In most civilized democratic countries and also the European Union
the primary laws (constitutions) offer protection of citizens 
against any form of discrimination and primitive harassment.

If one would have the opinion that these constitutional laws
are not good enough and/or that these laws are not completely respected
then I'd suggest to take part in democratic processes to improve this
situation.

If one cannot obey these laws, then, for example:

-Move to a country e.g. with an undemocratic, human rights ignoring
government,
 mostly dictatorial ones, which might suit one's anti social discriminating
behaviour better.
 (probably the most ultimate environment to get acquainted with one's own
shortcomings) 

-try to be more emphatic, this world is overpopulated, with high stress
levels, 
  an incredibly fast changing environment, where empathy 
  and social behaviour are more important than ever.

Ergo: 
In short if one harasses, discriminates people, one is violating the law.
There is no place for this on forums, 
There is no place for this anywhere in a civilized world.

As stated in the European constitution:
"The Union's values.
The Union is founded on the values of respect for 
human dignity, freedom, democracy, equality,
 the rule of law and respect for human rights, 
including the rights of persons belonging to minorities.
These values are common to the Member States in 
a society in which pluralism, non-discrimination, tolerance, 
justice, solidarity and equality between women and men prevail"

This is written on page 17 art: I-2 in
https://europa.eu/european-union/sites/europaeu/files/docs/body/treaty_establishing_a_constitution_for_europe_en.pdf

After this I will only enter this forum with IT / Smalltalk related
themes. That is the purpose of this forum.
Kind Regards.
TedvG










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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Sorry for the later response. yes here too: resizing didn't cause problems.
Drastic work around :o)   :
I have now installed Pharo 7.0 on my other Windows 10 PC,
Using the Pharo Launcher. **
Everything works ok, on my windows machine.
installed Seaside, my own app dev from .st fileins. etc.
Great!

Enjoying the improved 7.0 version.

Thanks to all
Kind regards
TedvG

**
(still having a problem here with Pharo Launcher)
   If I do "save as" in Pharo, the new image does NOT appear in the launcher
Window,
  why is that? 
  Pharo does also not respect the traditional "save as"  default renaming.
  It does not supply the old image name name with the new incremented
.number trailing.
  
  Solved the problem by putting my most recent .image .changes .source 
files
  into a separate independent  folder and making a Windows file association
to the new VM.
  which by the way is my preferred way of working, completely local, off
line,
  putting everything related to a single app development 
   in one autonomous folder. (I don't use git for my own developments..)
   Now, to work with an .image, I simply click on it and the VM starts with
that image,
   what can be simpler? 
  I don't need the nested folder structure the Pharo Launcher uses.
In practice, this means the Pharo Launcher is only useful to me to get
the most recent VM & image, whenever the need arises.







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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Tim,

I did that before (see thread history) and other kinds of magic too. 
Probably (still) a VM error? (because it happens with squeak also, which
uses same VM?) 
 
However, it is beyond my skills and knowledge
No idea how to solve this.

The problem has been around for much too long 
It bounces people away that arrive for the first time at Pharo/Smalltalk. 
(and they surely won't know about a workaround)

When the first simple things they try freezes the whole environment, 
they'll go away and probably never return.
That was then their first and last impression of Smalltalk.

TedvG



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

To All
(this thread becomes a bit long) 
Ca. 4 months later:
Today 2 Aug 2019 I did this:
-downloaded and run Pharo Launcher.
  -In the launcher, downloaded and started the fresh Pharo 7.0 64 image

Pharo then starts up with this image 

(but did it also launch with the most recent VM it could find on the server
or did it take a VM from somewhere on my Mac Mini?
Should I remove all VMs etc. from my Mac?
I did that also 4 months ago but that didn't help either...)


In Pharo, all I did was this:
  - did go fullscreen (4K), still working.
  - selected dark theme from the introduction window.
  - Opened "Appearance" menu
  - changed the appearance with one click to "Medium"
(now showing readable fonts on my 4K screen)
  - changed background to nice blueish gradient.
  - selected fullscreen in top menu to toggle back to a window.
Nothing happens and Pharo is frozen again
Forced quit Pharo was the only thing left to do.

So this is still a problem, leaving me to fall back again to Pharo 5.0 
(Is still OK, but not what I desire. 5.0 is the last version that doesn't do
these things.)

Kind Regards
TedvG









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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Thanks, but I will revert to Pharo 5.0 (pre spur VM)  again...
until the problems with 7.x are solved... or 8 is really stable.

I was regularly telling colleagues with whom I converse on Twitter
(e.g. Swift, C# and other programmers) 
that they should try Smalltalk, especially Pharo,
to see for themselves that programming in Smalltalk 
has many advantages, which however only become 
obvious when actually using Smalltalk. 
So I wrote tweets like
"try it for a week, and you'll be hooked" etc.
So people perhaps downloaded Pharo, but then
to get frozen in a mere minute..

if the *first experience* of those new to Smalltalk
is a freezing Pharo immediately after going full screen
or moving the window.
they might (probably will) think 
"ok, agreed, nothing is perfect, but so much for Smalltalk then, wasting my
time" 
never to return to Smalltalk again.  
Of course, that's really not good at all.

How can one promote Smalltalk if this kind of things happen?
Please note that this is not meant as a negative comment,
because I know that there are not many people
working on Pharo, but those that do, do the best they can!
However, it is unfortunately the status quo.
Very bad, because it bounces away those
who would really like to try Pharo
and might become enthusiastic Smalltalkers.

"Under the hood", need to know? 

New users know nearly nothing about VMs and how they
work. They shouldn't have to.
Let alone hacking VMs etc. to get Pharo going.
(respect btw for those building VMs, this is
not trivial, but this is exactly the reason why it is not a "user thing")

(I am profiling myself here as a typical Smalltalk
user, application programmer. 
Not a tool builder, I know almost nothing about VMs
(Do I have to?) and the deepest system related classes
in the Smalltalk deep sea. Initially, I live on the surface, and
only dive deeper when needed, so to speak.
e.g. looking for base classes like Morph.
If I go deeper, I might run out of mental oxygen :o) 
It is nearly impossible to know all classes living
in a Smalltalk image. (Seems this ocean metaphor is a 
nice one, we know more about (the surface of) the moon
 than about what is in the the depths of our oceans :o) )

All they (should care about) is learning/using
Smalltalk from an application programmer's perspective.

Perhaps it might be a good idea
to make it clear on the Pharo website
that version 5.0 (non spur VM) is the most recent stable version.
when using Pharo for safe reliable application building.
Focus on stable releases, add new things only after that.
(this might sound not too academic, 
but down-to-earth industrial, and yes it is) 

AndPlease   Keep   It  Simple: 
just a no frills one-click-image will do.
no hassle with launchers, loaders etc. 
For example you can still download
Blender (www.blender.org)
A large 3d application in a zip file
which is a single complete app directory with everything in it.

Thanks
TedvG






Ben Coman wrote
> On Tue, 30 Apr 2019 at 17:44, Stephan Eggermont <

> stephan@

> > wrote:
>>
>> TedVanGaalen <

> tedvga@

> > wrote:
>> > Crying victory too soon:
>> > Alas, it happened again pharo screen frozen,
>> > partly drawn, when going to full screen
>> > ( see image.)
>> > frustrating.
>> > The strange thing however:
>> >  the Seaside/Zinc server
>> >  kept running that is: I could enter  and save data in
>> >  in my test app running in the web browser!
>> > No idea why.
> 
> If you hit 
> 
>  do you see an option for Debug Options > Dump XXX
> maybe(?) provide some extra info.
> 
>>
>> That is consistent with other reports. Looks like the event loop
>> receiving
>> keyboard and mouse events gets stopped and not restarted. The http server
>> runs in its own process
> 
> Its been a long time since I've played with Seaside.
> IIUC from Seaside you can get a console-like interface to execute
> commands(?)
> Maybe try...  WorldMorph installNewWorld
> 
> Also maybe try commenting out the call to #interCyclePause:.
> (btw, your CPU will max out)
> 
> cheers -ben





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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Crying victory too soon: 
Alas, it happened again pharo screen frozen, 
partly drawn, when going to full screen
( see image.)
frustrating.
The strange thing however:
 the Seaside/Zinc server
 kept running that is: I could enter  and save data in
 in my test app running in the web browser!
No idea why.
TedvG  






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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

FYI  FWIWfurther testing: 
Running 7.03 with the 20181039  VM
-loaded Seaside 3.3 from Git
-filed in my test web app + utils
everything working OK without any changes!
Thanks 
TedvG



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Forgot to mention : Tests were run with newest 7.03 image, also downloaded
today.



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Stephan

Yes, tested this briefly: I confirm that
  20181039 works, 201810230536 is broken 

The broken version freezes as soon as selecting full screen from the menu
it freezes also when resizing or moving the window. (after force quitting it
and restarting. 

The 20181039 on first sight seems to be OK, 
If it keeps working ok, I will use this VM from now on 
until Pharo is downloadable with the official correct VM
btw: 
PLEASE RETURN THE ONE CLICK IMAGE
I don't prefer the Pharo Launcher, rather have a one-click image:
no fuzz with an extra app, it works right out of the box
and I can have my own directory structure.
(that means here: having Pharo app, .image.1..x,  changes, Pharo source
and other relevant resource files in one project dedicated folder. )
So that everything I need for a project -including Pharo itself
is there, all I have to do is go to that folder.
call it what you will but I prefer this way of working,
don't care much if it uses a few 100 megabytes more.
"I Did It My Way" Frank Sinatra (I can't sing that good :o|   ) 
Regards
TedvG



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Stephan
yes, you wrote that already before, but
which specific VM from files.pharo.org? there are many.
TedvG



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Stephan,
Pending: (Which VM?) 
If you still think trying a VM with Pharo 7 on my Mac is
important for you to conquer the bug in the VM, 
then please tell me which VM I should try out on my Mac.
Regards
TedvG



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

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[TedVanGaalen]

@Esteban: 
Of course you are right that there are cases a standalone app would be more
convenient e.g. as you mentioned: graphical (image processing) apps, digital
audio workstations, like Cubase. In most cases these are the kind of apps
that deal with personal (local) data, which mostly is not connected to a
central data storage on a hosting system. 
In other cases that is for users having real time access to data stored on a
central point, web apps are preferable. Like the banking app, Internet
shops.

Also on a smaller scale as browser intranet apps e.g. small independent
firms, clinics Law firms, accountancies and so on. Of course these should
have web apps running in the firm's intranet only. These used to be client
server apps, mostly with thin clients or ven just terminals (VT100) for
example running on a mini computer e.g.  DEC PDP 11/xx. Even today,
mainframe applications all  run on the host. Access is by terminal only.
This is the most secure environment you can get. I initially grew up with
mainframe application programming btw.
So to me, it seems logical that -at least in a business environment- a
single application (or a group of those) running on a central system
(server) is preferable. 

There are many blogs and articles on the web that describe the pro and
contra of web apps versus standalone apps. For example this blog: 

http://www.paulgraham.com/road.html

(It's a bit of a long read, but I do recommend it)
Paul Graham describes this theme much better than I ever can do. Note that
this blog is written 18 years ago and he had to work with the technical
limitations of 2000 and before. Today web technology is far more advanced,
enabling us to make really professional web apps. Most limitations are gone.

Seen in this perspective, Pharo (or some other Smalltalk versions) combined
with Seaside are excellent tools to create versatile web apps in a
relatively short amount of time. I think the limitations of designing and
building professional web apps are perhaps much less than one might think.
Like with many other challenges, one gets better by actually doing it. 

Some other points I'd like to react on:

Dependency on 3rd party tools in combination with Pharo/Seaside?
As far as I know now, in Seaside itself that would be only Javascript and
jQuery? It is unlikely that these will disappear because the whole web world
depends on these two. In Pharo image itself that would in most cases be at
least a database like Postgress. 

If the need arises for special GUI web elements, these could be made
relatively easy in Smalltalk. And of course it all relies heavily on CSS
which is very advanced, but that's a good thing! A good book about CSS is
helpful. 

Yet another reason for me to make -even stand alone- apps with Pharo as
Seaside web apps is, that (at least for me) it is much harder to make a
native GUI app within Pharo. Using the browser as GUI is much easier.
Honestly, I doubt if this would be better if GTK is deployed as GUI? Also
one would be bound to the GTK style/appearance and some themes they might
provide. No such limitations exist using Seaside with good CSS styling. Also
GTK does not work on mobile devices. So for me GTK or any other native GUI
are out because of that. 

On a Mac (similar on Windows btw) GTK needs an extra layer. It uses the
Quartz backend. GTK is not feature complete, riddled with bugs e.g. Wacom
tablets with GIMP), new releases are not compatible etc. See for yourself.
Don't stick your heads in a wasp nest. I don't understand why one would have
to, because Pharo has excellent GUI elements. You could subclass Morph
classes.? (I am not aware of most further GUI enhancements in Pharo, because
I still cannot run Pharo 7 on my mac mini due to a VM problem since 2017,
same with Squeak btw. (see other thread) still using pre-Spur Pharo 5)
Imho, by coupling GTK to Pharo one creates an unstable big dependency
situation. This stands opposite on having Smalltalk as autonomously and
independent as possible.


Errm, note btw that if you change addressing me as "fanatic" into "racing a
bit too fast"  i can accept this :o) 

(By "fanatic" I think of much worse things happening on our planet all the
time. So sad) 

The "always as web app, whenever possible" is something I strive for, not
that the whole world must do this. 

Thanks 
TedvG


































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

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[TedVanGaalen]

Hi Esteban 
let me write an example: (lots of time at the moment)

Hypothetical CASE 1 Stand Alone Solution:

Currently it's just a pilot/study project, but let's assume for a moment
that after a year so of really hard working on it in Pharo, I finally
completed my dental application system, that is, as as a stand-alone desktop
application...

After splatting a few initial bugs, the dental clinic is happy with my new
dental application, and they paid my bill. Mods were relatively easy to
implement, because it is Smalltalk, not to mention the fantastic debugger
facilities, simply very cool. 

They need to run the app simultaneously on 4 computers: that is 4 stand
alone apps running their own separated Smalltalk images. Using a Postgress
server as a DB on one of their PCs tied everything together. Apart from
having to install live Smalltalk images om each computer, backing them up
etc. not much of a problem, one would think, right? So far so good. ...apart
from having to install and maintain the app on each and every computer they
use, that is...

Two weeks later after my app went real: The clinic is expanding and another
3 computers will be added soon, meaning yet even more to install and
maintain. Hey! also a new update of Pharo arrives, I need to update 7 images
import my apps packages in the new images again. ( let alone the many system
updates on especially Windows machines) Test if everything works ok again
etc. Having no down-time is crucial: all done outside of the clinic's
working hours, of course. Great.

Oh, I almost forgot: they will install a iPads and/or Android tablets soon,
which will mounted close near each patient chair. They do that anyway
because analytical imaging apps and a drill controlling app of other firms
run on these tablets. They would be happy if they could run my dental app on
these tablets too, so they don't have walk back and forth to their PCs all
the time.

Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't
run on these tablets! What can I do? 
Write special versions of my app for Androids and iPads? Impossible! this
would take me a year or so. Nightmare.

In the end the clinic dumped my app and thus me, and bought another app from
another firm, which runs on all devices because it is a web app. How could I
be so stupid not to make it a web browser app in the first place?

Hypothetical CASE 2: App as Web Browser App:

Took a more modern approach: programmed my app for user access via a web
browser, A web browser is, if you really look at it, in fact nothing more
than a very advanced user terminal with endles GUI possibilities. Which btw
allowed me to style the app esthetically in any way my customer likes. Now
the cool thing is, on many devices, whether PCs, Macs, Android and Apple
tablets and Phones the user GUI presentation and interaction is nearly
identical. Which implies, I have to write my dental app only once, and it
will run on any device that is connected to an intranet or internet.  Not
only that, there is  just *one* single Pharo Image running instead of many
stand alone apps on an ever changing nr of computers. .When installing a new
Pharo version or update the app, I test it on another Pharo/Seaside server
and can switch seamlessly between the two. The dental clinic is happy
because it runs flawlessly on all devices they have and expanding or
shrinking the number of devices is no problem. Not only that, In case of
problems one can switch in no time to the shadow server app so we have
continuity here.

There is another important advantage as well. The users interacts with the
app in a browser window only, (a thin client)  that means they don't have
access to the real application, that is, the delicate Smalltalk image of the
Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a
locked room with an emergency power supply of course, together with its
friend the Database, and the room is only accessible by a responsible
employee(s). 

I am happy too, not only because the customer is, but also because I avoided
a nightmare and can do maintenance and updates, say, in 5 % of the time
needed when I had to do maintenance for e.g. 7 stand alone apps running om
separate computers.
- 
So far for my hypothetical examples, just to illustrate.

Note that on the internet, each site that you might visit is of course a web
app of its own. So you probably interact with more web apps than you'd
realize. Note that some are really advanced like e.g. web shops like Amazon.
There are many good websites that function really great, but a lot are
almost depressing. You're absolutely right that a lot of it is inferior, but
you might have noticed also that things are slowly improving.  

This bad quality with (still) many web apps/sites is because as you know
these are mostly built with chaotic hybrid systems/tools and unsafe
languages like Javascript, ever changing packages, interfaces, tools etc.  

Compared to that, 

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

[TedVanGaalen]

"Because there is still an important place for desktop applications market
and most medium-size 
 to big business still require them."
Really? Most things run on browsers these days.

Why would I need a GTK layer? 
(btw, GTK is yet another dependency on a 3rd party package) 
In my opinion 
the most versatile and advanced user application 
interface is: 
almost any internet browser!

Through all these many years, internet browsers have evolved into
excellent GUIs with endless possibilities for style (css)
formatting, fonts, colors, buttons etc. Extremely flexible. you can even
include
all sorts of plugins, Also you can use image morphs for graphs etc. 
What runs in a browser is computer independent, you'd cover many devices
(phones, pads, pc, macs, tv, etc) in one go.
In many cases, you don't even have to manage layout, browser does it for
you.
What more to wish for?

I could ask then, why implement similar GUI stuff, writing tons of
classes that interact with GTK, when internet browsers offer 
already a myriad of far more advanced features? 
Why re-invent the wheel? 

The combination Pharo with Seaside (or equivalent) is very powerful. 
Sure, there might be some situations where using a browser as
user interface is not desired or adequate, but currently I can't think of
one.

So Imho best thing to do is:
***Always make any user app as a web app!***
Which of course you can run "stand alone" with Pharo/Seaside as server
e.g. localhost:8080/yourApp

If one day a user would like to use their app via the internet, 
then no changes are needed because the app was already 
initially made for an internet browser as GUI, so it will run anywhere. 

To make apps that way the Pharo IDE as it is now stand alone is a pleasure.
I am currently restarting my app dev with Pharo/Seaside.
The image is a start of the dental app I am making, far from complete, but
I am sure you'll get the general idea. 
Regards
Ted
 



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Stephan 
I am a bit confused, not really at home in your VM world,
so please send me a link for the VM + an Image that you'd like me to try on
my mac.
Thanks 
Ted




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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

ok, I'll try 
please give me a link to that VM  20182039
can't find it here:
https://files.pharo.org/vm/pharo-spur64/mac/

TedvG



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Thanks for the Info/Link, Stephan

So it is a VM error then?

Guess we'll have to wait for a VM + Pharo 7.xx combo that works correctly on
macOS.

I now re-installed Pharo 5.0 (pre spur vm) 
loaded Seaside with Zincserver (using gofer) into it and my .st files from
2011...

might be a bit slower perhaps, but this 5.0 Pharo version works flawlessly. 
well, apart from the bugs in the dental app i'm building of course,
but that's my problem :o) 

Regards
Ted





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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Did just try with scaled resolution 1920 * 1080 (on my 4K screen) to no
avail.
same error:freeze with "toggle full screen"



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hope stack tells more. 
Could dig out an old hdmi HD monitor from 
unpacked moving cartons somewhere,
tell me you don't need me to do so :o\



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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

from the other terminal window:

teds-personal-mac-mini:~ TedvG$ ps -a | grep pharo
  811 ttys0000:00.01 bash ./pharo-ui Pharo.image
  815 ttys0000:10.06
/Users/TedvG/pharo-vm/Pharo.app/Contents/MacOS/Pharo Pharo.image
  824 ttys0010:00.00 grep pharo
teds-personal-mac-mini:~ TedvG$ kill -SIGUSR1 815
teds-personal-mac-mini:~ TedvG$ 





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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

and so i did. result   (the omega was a ctrl z to get up. had to open another
term. window to kill and dump. see here:
=
teds-personal-mac-mini:~ TedvG$ ./pharo-ui Pharo.image 
Ω   


SIGUSR1 Wed Apr 17 17:45:27 2019


VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

C stack backtrace & registers:
rax 0x0004 rbx 0x4f9f rcx 0x7ffee4b8df18 rdx
0x7ffee4b8dfd0
rdi 0x rsi 0x rbp 0x7ffee4b8e100 rsp
0x7ffee4b8df18
r8  0x7ffee4b8df40 r9  0x0090 r10 0x7ffee4b8df50 r11
0x0297
r12 0x7ffee4b8dfd0 r13 0x7ffee4b8df50 r14 0x7ffee4b8df40 r15
0x000d431d82f75f17
rip 0x7fff6db6361a
0   libsystem_kernel.dylib  0x7fff6db6361a __select + 10
1   Pharo   0x00010b0c7642 reportStackState
+ 952
2   Pharo   0x00010b0c7860 sigusr1 + 182
3   libsystem_platform.dylib0x7fff6dc0cb5d _sigtramp + 29
4   ??? 0x7ffee4b8da07 0x0 +
140732735740423
5   Pharo   0x00010b0cab6d
ioRelinquishProcessorForMicroseconds + 53
6   Pharo   0x00010b07fda7
primitiveRelinquishProcessor + 54
7   ??? 0x00010f70b32b 0x0 + 4554011435
8   Pharo   0x00010b03f23a interpret + 628
9   Pharo   0x00010b0c8dca
-[sqSqueakMainApplication runSqueak] + 393
10  Foundation  0x7fff43890dd6
__NSFirePerformWithOrder + 362
11  CoreFoundation  0x7fff41571c94
__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
12  CoreFoundation  0x7fff41571bc9
__CFRunLoopDoObservers + 451
13  CoreFoundation  0x7fff4151474e __CFRunLoopRun +
1143
14  CoreFoundation  0x7fff41514085
CFRunLoopRunSpecific + 459
15  HIToolbox   0x7fff407f29db
RunCurrentEventLoopInMode + 292
16  HIToolbox   0x7fff407f261d
ReceiveNextEventCommon + 355
17  HIToolbox   0x7fff407f24a6
_BlockUntilNextEventMatchingListInModeWithFilter + 64
18  AppKit  0x7fff3eb8cffb _DPSNextEvent +
965
19  AppKit  0x7fff3eb8bd93
-[NSApplication(NSEvent)
_nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
20  AppKit  0x7fff3eb85eb0 -[NSApplication
run] + 699
21  AppKit  0x7fff3eb753f0 NSApplicationMain
+ 777
22  libdyld.dylib   0x7fff6da273d5 start + 1
23  ??? 0x0002 0x0 + 2


All Smalltalk process stacks (active first):
Process0x113277e80 priority 10
0x7ffee4b9a0b0 M ProcessorScheduler class>idleProcess 0x11009d660: a(n)
ProcessorScheduler class
0x7ffee4b9a0f0 I [] in ProcessorScheduler class>startUp 0x11009d660:
a(n) ProcessorScheduler class
0x7ffee4b9a130 I [] in BlockClosure>newProcess 0x113282088: a(n)
BlockClosure

suspended processes
Process0x11327a9e0 priority 50
0x7ffee4b960b0 I WeakArray class>finalizationProcess 0x11009e420: a(n)
WeakArray class
0x7ffee4b960f0 I [] in WeakArray class>restartFinalizationProcess
0x11009e420: a(n) WeakArray class
0x7ffee4b96130 I [] in BlockClosure>newProcess 0x113646fa8: a(n)
BlockClosure

Process0x11299b5a8 priority 80
0x7ffee4b910e8 M DelayMicrosecondTicker>waitForUserSignalled:orExpired:
0x1104db528: a(n) DelayMicrosecondTicker
0x7ffee4b91130 M [] in
DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority
0x1104d03c0: a(n) DelaySemaphoreScheduler
   0x1132542e8 s BlockClosure>ensure:
   0x11298a590 s
DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority
   0x113242ee8 s [] in
DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority:
   0x11298a668 s [] in BlockClosure>newProcess

Process0x113277e30 priority 60
0x7ffee4b940b0 I SmalltalkImage>lowSpaceWatcher 0x1100ab9a8: a(n)
SmalltalkImage
0x7ffee4b940f0 I [] in SmalltalkImage>installLowSpaceWatcher
0x1100ab9a8: a(n) SmalltalkImage
0x7ffee4b94130 I [] in BlockClosure>newProcess 0x113646e80: a(n)
BlockClosure

Process0x113277ed0 priority 60
0x7ffee4b92068 M InputEventFetcher>waitForInput 0x1107ef020: a(n)
InputEventFetcher
0x7ffee4b920b0 M InputEventFetcher>eventLoop 0x1107ef020: a(n)
InputEventFetcher
0x7ffee4b920f0 I [] in InputEventFetcher>installEventLoop 0x1107ef020:
a(n) InputEventFetcher
0x7ffee

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Note! Just being playing a bit further with Squeak 5.2
and it freezes too, when resizing the window!
Similar things in VM ?
Regards
TedvG




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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Sure. Which one? and with what image?
However, don't know if that would make a difference,
because I've been trying this repeatedly since Pharo 6.0

Squeak 5.2 (just downloaded and launched just to try) works ok,
but for what I do, and previous work/classes made with Pharo 5.0,
Pharo/Seaside would be preferable.
Squeak uses another VM or so it seems
(thought for a moment VMs were the same,
that's why I tried Squeak,)

regards from Souillac. (F) 
TedvG

>From Squeak About

/Applications/Squeak5.2-18229-64bit.app/Contents/Resources/Squeak5.2-18229-64bit.image
Squeak5.2
latest update: #18229
Current Change Set: Unnamed1
Image format 68021 (64 bit)

Virtual Machine
---
/Applications/Squeak5.2-18229-64bit.app/Contents/MacOS/Squeak
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives
VMMaker.oscog-eem.2461] 64 bit
Mac OS X built on Oct 20 2018 08:16:09 UTC Compiler: 4.2.1 Compatible Apple
LLVM 7.3.0 (clang-703.0.31)
platform sources revision VM: 201810190412
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Oct 18
21:12:21 2018 CommitHash: 15341b5 Plugins: 201810190412
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-eem.2461 uuid:
b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 20 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid:
0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 20 2018



 




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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Sven
-launched the original image again.
-dragged the Pharo window to almost full screen, (4K) 

  it then gets redrawing problems: 
  - drawing the window contents partly 
  - and in the wrong places
  and after a short time then freezes again.
  Exactly the same symptoms as described previously in this thread in 2017.

I tried this several times: launching Pharo with the original pristine
image.
dragging the window bigger, hitting the green bullet + option key etc. 

I have no idea why. frustrating. want to get things done with Pharo.

Is pharo tested on 4K macs and/or mac mini with 4K screens?
so on anything with this resolution?

Does Pharo or the VM emit a post-mortem log/dump file? cannot find any. 

All other apps run without problems and Pharo 5 did also run OK.

TedvG






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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hi Paul
thanks for responding.

what I did now:
- removed all Pharo apps & images etc. from my system
(no problem, i have all i need backed up in .st and .mcz files)
followed your instructions to install the latest VM and Image:

 terminal log: ===

teds-personal-mac-mini:~ TedvG$ curl https://get.pharo.org/64/ | bash
  % Total% Received % Xferd  Average Speed   TimeTime Time 
Current
 Dload  Upload   Total   SpentLeft 
Speed
100 12695  100 126950 0  53119  0 --:--:-- --:--:-- --:--:--
53117
Downloading the latest 70 Image:
http://files.pharo.org/get-files/70/pharo64.zip
Pharo.image
Downloading the latest pharoVM:
http://files.pharo.org/get-files/70/pharo64-mac-stable.zip
pharo-vm/Pharo.app/Contents/MacOS/Pharo
Creating starter scripts pharo and pharo-ui
teds-personal-mac-mini:~ TedvG$ ./pharo-ui Pahro.image
teds-personal-mac-mini:~ TedvG$ ./pharo-ui Pharo.image
teds-personal-mac-mini:~ TedvG$ ./pharo-ui version
teds-personal-mac-mini:~ TedvG$ ./pharo-ui --version
5.0 5.0.201901051900 Mac OS X built on Jan  5 2019 19:11:02 UTC Compiler:
4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur 64-bit
VM]
CoInterpreter VMMaker.oscog-eem.2504 uuid:
a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid:
a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan  5 2019
VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6
Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git

teds-personal-mac-mini:~ TedvG$ ./pharo-ui Pharo.image
./pharo-ui: line 11:  1539 Terminated: 15 
"$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@"
teds-personal-mac-mini:~ TedvG$ 
end terminal log 

In the above as yet unchanged new image, I did nothing else
than "toggle full screen mode"  in the menu bar
Pharo then freezes. had to kill it with force quit.

As you can see in the terminal log, it emits this line when/before freezing:
./pharo-ui: line 11:  1539 Terminated: 15 
"$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@"
Maybe this is helpful.
Would be strange if I am the only one with this problem?
Kind regards
TedvG
 




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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Hello


The freeze problem still exist. (since 2017, starting with Pharo 6) 
16 April 2019:
Today I have loaded Pharo7.0.3-0-64bit-0903ade.image
with VM 
 

On my Mac Mini late 2012, mac OS Mojave 10.14.4 (OS up to date, system 100%) 
Monitor:
Samsung U28D590:
  Resolution:   3840 x 2160 (2160p 4K UHD - Ultra High Definition)
  UI Looks like:3840 x 2160 @ 30 Hz
  Framebuffer Depth:24-Bit Color (ARGB)

  Note that the same freeze as described previously in this thread 
still occurs with the latest Squeak version that
 I have downloaded and tried last  week. 
So this could be a VM problem? I really don't know.
All I want to do is write applications with stable Smalltalk/Seaside
no desire (and knowledge) enough to dive into the deep
and dark catacombs of the VM world.

what I did:
-opened the pristine image as downloaded today
- in Pharo - settings - appearance:
 changed the general font size to Large.
- opened the system browser.
- clicked the green bullet in the top left corner (maximize)
Pharo hangs/freeze, menus don't work either. 
Can only exit using Force Quit.
The last stable version I did use was Pharo 5.0.
The problem is still the same as I have described in this thread in August
2017.
I did use Pharo launcher a few weeks ago  (having the same problem) 
but this is not exactly user friendly, saved images where I don't want to.
and "Save as from within the image is not respected" 
I prefer to use just a VM and images, thats good enough for me.

Keep it simple.

I'd like to spend more time with Smalltalk, preferably Pharo.
In essence, I do like new developments like enhanced
system browsers and debugging
that might improve Pharo.
But one might be overshooting the target here,
I find rocksolid stability more important,
than adding more features, so, this should be the main priority,
that is, assuming that Pharo should be deployable in a production
environment?
It is marked as "stable" but it isn't, sorry.
A good house needs a good foundation, same with Smalltalk.
But it seems we are living in a culture of nervous deadlines and hasty and
frequent updates,
is it really necessary?  

All I want is a one click vm + image, as it was before.
simply download and run it.
Why git btw? Smalltalk has an excellent version system,
by using git there is more dependency impact.

Now I am still using Pharo 5.0, the last (to me) stable version of Pharo.

Kind regards
Ted



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

Re: [Pharo-users] Problem loading image after changing resolution from 4Kto HD

[TedVanGaalen]

Thank you Stef
I'll wait and use Pharo 5.0 (on Mac and Windows) until this problem is
solved. No problem,
with Seaside and Postgress db installed in the 5.0 image, it provides all I
need. 
I will also do this on my MacMini, because it still hangs when switching to
and fro full screen,
as described previously described in a similar topic on this forum.
(wiped the complete 6.1 from my mac system and reinstalled it, 
hoping the problem was solved... to no avail.. 
[
btw,
Why on Earth is Pharo "becoming ensnared" :o) in Github,
I thought Monticello mcz is perfect equivalent for this?

But maybe I am asking such a stupid question like this because
I am a solo developer, using virtually no 3rd party software and
saving a version of the complete image/source each time I've made
significant changes.
(to me Github appears as unnecessary overhead and confusion)  
]  

Kind Regards
Ted

btw, i am 67 and retired (they tell me) , would Perpignan be a 
nice place to live, as an active IT pensionado?
considering moving South end 2018 if money permits..






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

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Hi Stephane, Ben

In the Smalltalk world, you could value me as a relatively "simple"
application developer  as a first attempt after a long time, I am trying to
make 
a dentist's app with Pharo Smalltalk.  
(The intend is to use Smalltalk (Pharo) with Seaside and Postgress whenever
possible,
because today, Smalltalk is fast enough for most applications)

At deeper levels, like working or even adequately understanding the inner
workings of VMs
I virtually have no knowledge. This is not my terrain. Although this might
be interesting too,
 it would cost me weeks to get into that, before being able to do things
like debugging VM's...
 
So also due to time constraints , I'd have to refrain from that, sorry, 
also because I am currently working on a new version of my app RavelNotes. 
This is in Swift ( i can live with that) btw, because Smalltalk is not
available 
for making  native apps for iOS iPad. Would be an extremely daunting task 
to link all iOS libs etc into Smalltalk... 



cheers TedvG






--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4964995.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

note btw in the screenshot that that some text in the dialogue boxes are not 
completely drawn, like
“Advanced featur..”, "Cache siz…”, “Glyph contras…”, etc.
this doesn’t change when the column width is increased with the mouse.
TedvG 

> On 25. Aug 2017, at 15:55, Ted F.A.van Gaalen  wrote:
> 
> Hi Ben,
> Did the following 
> - restoring Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib (by renaming 
> its extension back to .dylib)
> - started Pharo
> -setting use Free type ON
> -setting Update fonts at start ON
> 
>it then immediately starts loading fonts, (which I thought might be a good 
> idea
>  because perhaps fonts were not completely loaded in the image, 
> but that didn’t make any difference) 
> 
> -saved and quit
> -fired up Pharo again.
> 
> didn’t help. Same problems occur
> 
> then:  (as you have asked) 
> 
> - started Pharo again
> -setting use Free type OFF
> -setting Update fonts at start OFF
> -saved and quit
> -fired up Pharo again.
> 
> didn’t help either
> 
> I have no idea what the cause might be,
> but if you have other suggestions to test
> I be glad to help. (if not a thousand attempts :o) 
> 
> in the mean time I use 5 until a next release comes out 7 ? that works ok.
> 
> kind regards
> TedvG 
> 
> 
> 
> 
>> On 25. Aug 2017, at 06:07, Ben Coman [via Smalltalk] 
>> > <mailto:ml+s1294792n4963983...@n4.nabble.com>> wrote:
>> 
>> What happens if you untick "Use FreeType" in System > Settings?
>> 
>> cheers -ben
>> 
>> 
>> On Thu, Aug 24, 2017 at 10:06 PM, TedVanGaalen <[hidden email] 
>> > wrote:
>> yes, after full screen -> normal window -> minimise -> reshow it did. 
>> (not in any particular order, tried al those before as well)
>> 
>> TedvG
>> 
>> 
>>> On 24. Aug 2017, at 15:46, EstebanLM [via Smalltalk] <[hidden email] 
>>> <http://user/SendEmail.jtp?type=node&node=4963891&i=0>> wrote:
>>> 
>>> and image still freezing?
>>> 
>>> Esteban
>>> 
>>>> On 24 Aug 2017, at 15:28, TedVanGaalen <>>> target="_top" rel="nofollow" link="external" class="">[hidden email]> 
>>>> wrote:
>>>> 
>>>> Hi Esteban, 
>>>> unfortunately that doesn’t make any difference.
>>>> What I did: 
>>>> extension temporarily renamed to …..wasAdylib
>>>> Started Pharo app by clikcing on it (gets the downloaded  maiden image)
>>>> then:
>>>> “FT2Error:Freetype2 primitive failed [error -1][can’t get error string]” 
>>>> 
>>>> 
>> 
>> 
>> 
>> If you reply to this email, your message will be added to the discussion 
>> below:
>> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963983.html
>>  
>> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963983.html>
>> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
>> <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4957969&code=dGVkdmdhQGdtYWlsLmNvbXw0OTU3OTY5fDE3Mzc5OTA3NjY=>.
>> NAML 
>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>





--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4964088.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Hi John,
… thanks. another wild, wild guess:
it could then perhaps be, (if Pharo uses Open GL) that my graphics
card has Open GL incompatibility?  or that Pharo 6.1 uses Open GL
calls not implemented on an  Intel HD Graphics 4000  chip as in my mac mini?

kind regards
TedvG



> On 25. Aug 2017, at 06:56, John Pfersich [via Smalltalk] 
>  wrote:
> 
> I don't know if it matters, but on my Retina 5K, 27 inch, Late 2015 iMac, AMD 
>  Radeon R9 M395 wirh 2048 MB running MacOS 10.12.6 I don't have a problem 
> resizing or maximizing Pharo 6.1.
> 
> On Mon, Jul 31, 2017 at 6:28 AM, Ted F.A.van Gaalen <[hidden email] 
> > wrote:
> 
> 
> 
> Hi, I reverted to 5.0 because Pharo 6.0 and 6.1 64 bit hangs on 
> my Mac Mini with UDH 4K screen (may that has to do with?)
> with its maiden image (at first start after download
> when:  I resize or go to full screen. Maybe VM problem?
> my mac Mini metrics:
> Hardware Overview:
> 
>   Model Name: Mac mini
>   Model Identifier:   Macmini6,2
>   Processor Name: Intel Core i7
>   Processor Speed:2,6 GHz
>   Number of Processors:   1
>   Total Number of Cores:  4
>   L2 Cache (per Core):256 KB
>   L3 Cache:   6 MB
>   Memory: 4 GB
>   Boot ROM Version:   MM61.0106.B1F
>   SMC Version (system):   2.8f0
> 
> maybe this problem was already reported, but could find it. 
> 
> 
> Kind Regards
> TedvG
>  
>
> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963988.html
>  
> 
> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
> .
> NAML 
> 




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4964083.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Hi Ben,
Did the following 
- restoring Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib (by renaming 
its extension back to .dylib)
- started Pharo
-setting use Free type ON
-setting Update fonts at start ON

   it then immediately starts loading fonts, (which I thought might be a good 
idea
 because perhaps fonts were not completely loaded in the image, 
but that didn’t make any difference) 

-saved and quit
-fired up Pharo again.

didn’t help. Same problems occur

then:  (as you have asked) 

- started Pharo again
-setting use Free type OFF
-setting Update fonts at start OFF
-saved and quit
-fired up Pharo again.

didn’t help either

I have no idea what the cause might be,
but if you have other suggestions to test
I be glad to help. (if not a thousand attempts :o) 

in the mean time I use 5 until a next release comes out 7 ? that works ok.

kind regards
TedvG 




> On 25. Aug 2017, at 06:07, Ben Coman [via Smalltalk] 
>  wrote:
> 
> What happens if you untick "Use FreeType" in System > Settings?
> 
> cheers -ben
> 
> 
> On Thu, Aug 24, 2017 at 10:06 PM, TedVanGaalen <[hidden email] 
> > wrote:
> yes, after full screen -> normal window -> minimise -> reshow it did. 
> (not in any particular order, tried al those before as well)
> 
> TedvG
> 
> 
>> On 24. Aug 2017, at 15:46, EstebanLM [via Smalltalk] <[hidden email] 
>> <http://user/SendEmail.jtp?type=node&node=4963891&i=0>> wrote:
>> 
>> and image still freezing?
>> 
>> Esteban
>> 
>>> On 24 Aug 2017, at 15:28, TedVanGaalen <>> href="x-msg://3/user/SendEmail.jtp?type=node&node=4963878&i=0" 
>>> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
>>> 
>>> Hi Esteban, 
>>> unfortunately that doesn’t make any difference.
>>> What I did: 
>>> extension temporarily renamed to …..wasAdylib
>>> Started Pharo app by clikcing on it (gets the downloaded  maiden image)
>>> then:
>>> “FT2Error:Freetype2 primitive failed [error -1][can’t get error string]” 
>>> 
>>> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963983.html
>  
> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963983.html>
> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
> <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4957969&code=dGVkdmdhQGdtYWlsLmNvbXw0OTU3OTY5fDE3Mzc5OTA3NjY=>.
> NAML 
> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


Screen Shot 2017-08-25 at 15.33.49.png (96K) 
<http://forum.world.st/attachment/4964080/0/Screen%20Shot%202017-08-25%20at%2015.33.49.png>




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4964080.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

yes, after full screen -> normal window -> minimise -> reshow it did. 
(not in any particular order, tried al those before as well)

TedvG


> On 24. Aug 2017, at 15:46, EstebanLM [via Smalltalk] 
>  wrote:
> 
> and image still freezing?
> 
> Esteban
> 
>> On 24 Aug 2017, at 15:28, TedVanGaalen <[hidden email] 
>> > wrote:
>> 
>> Hi Esteban, 
>> unfortunately that doesn’t make any difference.
>> What I did: 
>> extension temporarily renamed to …..wasAdylib
>> Started Pharo app by clikcing on it (gets the downloaded  maiden image)
>> then:
>> “FT2Error:Freetype2 primitive failed [error -1][can’t get error string]” 
>> 
>> 
>> 
>> 
>> this screen dump is after maximizing Pharo
>> (as can be seen only dragging window redraws areas it’s been on)
>> didn’t freeze this time but mostly after some time it will and have to force 
>> quite Pharo. 
>> 
>> 
>> 
>>> On 24. Aug 2017, at 14:42, EstebanLM [via Smalltalk] <>> href="x-msg://183/user/SendEmail.jtp?type=node&node=4963866&i=0 
>>> " 
>>> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
>>> 
>>> it may have something to do with FreeType. 
>>> Can you try removing/renaming 
>>> Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib ? 
>>> 
>>> (just to test) 
>>> 
>>> thanks, 
>>> Esteban 
>>> 
>>> 
>>> > On 24 Aug 2017, at 14:00, TedVanGaalen <>> >  
>>> > "
>>> >  class="">x-msg://1/user/SendEmail.jtp?type=node&node=4963855&i=0 
>>> > " 
>>> > target="_top" rel="nofollow" link="external" class="">[hidden email]> 
>>> > wrote: 
>>> > 
>>> > Yesterday 23 Aug, I completely deleted all Pharo 6.1 64 bit and then 
>>> > downloaded and reinstalled it, but the same problems are still present. 
>>> > 
>>> > Then I installed Squeak5.1-16549-64bit, which works without problems. 
>>> > (I don't know if it uses the same VM as Pharo 6.1 64 bit?, if that is 
>>> > true, 
>>> > then the problem could be within the image, not the VM?) 
>>> > 
>>> > However, I do prefer using Pharo. 
>>> > As written before, I'll use Pharo 5.0 until 6.x 
>>> > runs ok on my mac mini. 
>>> > 
>>> > kind regards 
>>> > TedvG 
>>> > 
>>> > 
>>> > 
>>> > -- 
>>> > View this message in context: 
>>> > http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963845.html
>>> >  
>>> > <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963845.html>
>>> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com 
>>> > <http://nabble.com/>. 
>>> > 
>>> 
>>> 
>>> If you reply to this email, your message will be added to the discussion 
>>> below:
>>> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963855.html
>>>  
>>> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963855.html>
>>> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
>>> .
>>> NAML 
>>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>> 
>> View this message in context: Re: Pharo 6.0 and 6.1 64 bit freeze on MacMini 
>> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963866.html>
>> Sent from the Pharo Smalltalk Users mailing list archive 
>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com 
>> <http://nabble.com/>.
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963878.html
>  
> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963878.html>
> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
> <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4957969&code=dGVkdmdhQGdtYWlsLmNvbXw0OTU3OTY5fDE3Mzc5OTA3NjY=>.
> NAML 
> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963891.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Hi Esteban, 
unfortunately that doesn’t make any difference.
What I did: 
extension temporarily renamed to …..wasAdylib
Started Pharo app by clikcing on it (gets the downloaded  maiden image)
then:
“FT2Error:Freetype2 primitive failed [error -1][can’t get error string]” 




this screen dump is after maximizing Pharo
(as can be seen only dragging window redraws areas it’s been on)
didn’t freeze this time but mostly after some time it will and have to force 
quite Pharo. 


> On 24. Aug 2017, at 14:42, EstebanLM [via Smalltalk] 
>  wrote:
> 
> it may have something to do with FreeType. 
> Can you try removing/renaming 
> Pharo.app/Contents/MacOS/Plugins/libFT2Plugin.dylib ? 
> 
> (just to test) 
> 
> thanks, 
> Esteban 
> 
> 
> > On 24 Aug 2017, at 14:00, TedVanGaalen <[hidden email] 
> > > wrote: 
> > 
> > Yesterday 23 Aug, I completely deleted all Pharo 6.1 64 bit and then 
> > downloaded and reinstalled it, but the same problems are still present. 
> > 
> > Then I installed Squeak5.1-16549-64bit, which works without problems. 
> > (I don't know if it uses the same VM as Pharo 6.1 64 bit?, if that is true, 
> > then the problem could be within the image, not the VM?) 
> > 
> > However, I do prefer using Pharo. 
> > As written before, I'll use Pharo 5.0 until 6.x 
> > runs ok on my mac mini. 
> > 
> > kind regards 
> > TedvG 
> > 
> > 
> > 
> > -- 
> > View this message in context: 
> > http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963845.html
> >  
> > <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963845.html>
> > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com 
> > <http://nabble.com/>. 
> > 
> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963855.html
>  
> <http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963855.html>
> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
> <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4957969&code=dGVkdmdhQGdtYWlsLmNvbXw0OTU3OTY5fDE3Mzc5OTA3NjY=>.
> NAML 
> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


Screen Shot 2017-08-24 at 15.10.30.png (174K) 
<http://forum.world.st/attachment/4963866/0/Screen%20Shot%202017-08-24%20at%2015.10.30.png>
Screen Shot 2017-08-24 at 15.18.10.png (448K) 
<http://forum.world.st/attachment/4963866/1/Screen%20Shot%202017-08-24%20at%2015.18.10.png>




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963866.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Yesterday 23 Aug, I completely deleted all Pharo 6.1 64 bit and then
downloaded and reinstalled it, but the same problems are still present. 

Then I installed Squeak5.1-16549-64bit, which works without problems.
(I don't know if it uses the same VM as Pharo 6.1 64 bit?, if that is true,
then the problem could be within the image, not the VM?) 

However, I do prefer using Pharo. 
As written before, I'll use Pharo 5.0 until 6.x
runs ok on my mac mini.

kind regards
TedvG



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4963845.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

ok, thanks, is there a difference in the 32 and 64 bit vm behaviour? it seemed 
to me they both had this error,
but I am a byte confused now. 
Anyway, for the time being it is not a problem to continue with Pharo 5.0.
TedvG

> On 16. Aug 2017, at 18:25, EstebanLM [via Smalltalk] 
>  wrote:
> 
> 
> > On 16 Aug 2017, at 16:55, Stephan Eggermont <[hidden email] 
> > > wrote: 
> > 
> > Please try starting your Pharo image with a new squeak vm. I remember 
> > Tobias posting something on a full screen bug fix about a year ago, and 
> > don't know what happened with it. It was around the same time as his hiDPI 
> > fix, which triggered some garbage collection issue at the time. Some part 
> > of that was then reverted. 
> 
> anything that is in the squeak vm is also in the pharo vm now (since we 
> merged). 
> so this recommendation is obsolete (thanks to the gods :P). 
> 
> Esteban 
> 
> > 
> > Stephan 
> > 
> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4961679.html
>  
> 
> To unsubscribe from Pharo 6.0 and 6.1 64 bit freeze on MacMini, click here 
> .
> NAML 
> 




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4961683.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Aha! similar here! Didn't do that before: resizing after freezing. So almost
sure it has to do with resizing only? 
1: after maximizing to full screen parts are not redrawn but still can drag
windows around:

 

2: then after coming back and reentering full screen the everthing is
redrawn again,(can't
remembering opening a Test Window probably clicked on a non refreshed part
in window)
But when dragging windows parts are not redrawn (you can see almost exactly
where I dragged
because the gradient background reveals differences if you'd look closely.
Still, Pharo is still alive. but doesn't redraw the parts when e.g.
evaluating
something in a Playground as can be seen in the last 3rd screen dump.

 

 

 

So, in summary: resizing the screen in any way can freeze/unfreeze Pharo
again and
screen redrawing is in error. 
TedvG



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4961655.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

here's a screenshot. notice the white band in the content area after
maximizing the window. It freezed, can't move the inner windows anymore and
ctrl '.' user interrupt doesn't work and have to force quit Pharo. No idea
what happens but Pharo 5.0 runs as stable as ever.
Kind Regards
TedvG
  



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4961631.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

The screen is a Samsung U28D590 3840 x 2160 @ 30Hz (max reso on intel 4000
graphics) via a Thunderbolt->DisplayPort cable. Initially not directly
supported, that is, the resolution was not recognized by the OS as-is, but
has been enabled with the SwitchResx app here http://www.madrau.com/  which
somehow tweaks the system telling it about this new resolution. Many use
this utility app. It runs OK from the start since summer 2015. Pharo 5.0
runs fast and stable without problems. 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960221.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Well, I am in Speyer, Germany,
 
probably too far away, 

Although not really good in low level debugging
nevertheless, if I can help in some way, 
please let me know!

Does it run OK then on other 4/5K screen macs? 

TedvG

www.speyer.de



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960190.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

.. hard to imagine I am the only one with this problem? 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960027.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

thanks for you reply, Esteban

well, I can still use Pharo 5 in the mean time, no problem.
how/where should I forward this to vm-dev?

Regards, have a nice holiday!
Ted 



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4960023.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

since 1.8.2017 there was no response, did already anyone thought/worked to
solve this problem?
Thank you,
Ted

TedVanGaalen wrote
> Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo
> call time out issues because the Intel HD 4000 GPU is working at its
> (officially allowed) upper performance limits with 3840 x 2160 at 30 Hz
> refresh rate (maximum).
> OTOH however:  
>   1.  I am not a GPU Guru.. 
>   2.  It works flawlessly with Pharo 5.0 and before.
>   3.  All other macOS applications also work OK. 
> 
> If it is a VM issue, Squeak would have the same problem
> but I don't want to spend time to try this as well.
> 
> TedvG





--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4959933.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Very very wild guess: it could have to do with GPU<-> Open GL? <-> Pharo call
time out issues because the Intel HD 4000 GPU is working at its (officially
allowed) upper performance limits with 3840 x 2160 at 30 Hz refresh rate
(maximum).
OTOH however:  
  1.  I am not a GPU Guru.. 
  2.  It works flawlessly with Pharo 5.0 and before.
  3.  All other macOS applications also work OK. 

If it is a VM issue, Squeak would have the same problem
but I don't want to spend time to try this as well.

TedvG



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4958190.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

Hi, 
I have now tried to run Pharo 6.1 32 bit with 
setting the screen resolution in 
macOS System Preferences to the following
what they call "scaled resolutions" (read "non-native resolutions"), 
which are less that the native screen resolution:
3200 x 1800  and
1920 x 1080.
In these resolutions the Pharo 6.1 32 bit works OK: 
that is, when repeatedly switching
to and from full screen (using the green window button
in the upperleft corner) the Pharo window content is then
instantly correctly redrawn. Which is not the case with
native UHD resolution: when maximizing the window is
not redrawn and leaves white bands at the top and left side.
if I e.g.moved an internal window like the system browser
downward repeated window parts remain where it was.
Which typically is a window redraw issue.
It then gets very sluggish and in the end freezes.
I then have to Force Quit the app. 
Unfortunately Pharo dies then to fast to give some
post-mortem crash.dmp. 

I assume that other crashes, that is e.g. with dragging the Playground
also caused it to freeze, because of redraw issues, which occur
likewise in the 32 and 64 bit version of Pharo version > 6.0
with this UHD resolution.

So, my guess is that drawing on macOS with the
native resolution UHD 3840 * 2160 still has a bug.
I'd suggest that perhaps comparing the graphic driver logic
with that of what is used in Pharo 5.0, which functions correctly, 
with UHD resolution might reveal the problem? 

Have you tested this on macOS with this UHD screens?
Will it/does it also crash also on 4k iMac and even 5k iMacs or only
on the Mac Mini? 

Thank you in advance for solving this problem, if possible. 

TedvG





--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4958189.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

- Do you have an exception? a PharoDebug.log file? a crash.dmp?
I didn't found neither of this files on my system.
TedvG



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4958167.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

OS = macOS Sierra Version 10.12.6

I have encountered the same behaviour for Pharo 6.0 and 6.1
64 bit or 32 bit, it doesn't matter.
Workflow:
Downloaded Pharo6.1-mac.zip and
placed the resulting .app file into the normal Applications folder
(a hit on the Pharo website recommends this for Sierra)

Started it from there and of course loads the included pristine image.

Because of my 4k screen the first thing that I did is
change fonts to "large" via System menu and then maximize the
window by clicking the little green icon in the top left corner.

Repeated this procedure several times (reinstalling etc.) sometimes
it froze instantly, sometimes after redrawing attempts, sometimes
it still runs and I can manually "repaint" the window by swiping a
playground window everywhere. at times it works ok but then
suddenly freezes after a few minutes or so e.g. when I save a
method. So, to me it is unpredictable. 
At times I've tried CTLR + "." sometimes it reacts but then
freezes again..
After that I've removed 6.1 64 bit version completely and
reinstalled it, this tim enot in the Applications folder but in
another folder on the Desktop, alas, to no avail, also for the 32 bit
version of Pharo 6.1.

Officially Apple does not support UHD 4k screens
on a Mac Mini from late 2012 with Intel HD graphics 4000.
However, like almost everybody else who uses 4K screens on this computer, 
I am using the SwitchResX app which tells macOS about this resolution, 
adjusting the parameters it is native 3840 x 2160 @ 30 Hz refresh rate.

Apart from some graphical glitches on the start up screen graphics
are perfect with all the apps I use, also for graphically intense apps
like Affinity Photo and Affinity Designer and even 4K videos.

If you are still using the same graphical interfacing in 6.x as in Pharo 5.0
this shouldn't be the problem, i think.? Nevertheless, yes. I will try with
a 
a lower non-native resolution later and let you know if that made
any difference.

Pharo 5.0 is completely stable and works flawlessly, with the
image with Seaside and Wooden (GL) loaded. No crashes at all.
really is great.

I am reviving my Smalltalk (my favorite programming system), 
because I prefer to write apps for mac, linux and Windows with it.
mostly as (local) webbrowser apps, with some Morphs put in it. 
This allows much faster developing and does not cause headaches :o)


I am also writing iOS apps (e.g.RavelNotes for iOS iPad and Apple TV (lots
of time,
retired in 2016) but this has to be done with Xcode and Swift,
with has increasingly complexity, which is inherent to statically typed
languages.
(like generics, protocols.etc.) No way (yet) to do this with Smalltalk, also
for 3D apps e.g. with SceneKit it's still not fast enough, which leaves me
no choice.

Thank you, kind Regards. Ted.

(I was also here in 2012, but was under tons of IT stress, which reflected
in 
my writing and responding, luckily this is gone) 




--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4958166.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini

[TedVanGaalen]

I've just installed the 32bit version. same problems here. freezes



--
View this message in context: 
http://forum.world.st/Pharo-6-0-and-6-1-64-bit-freeze-on-MacMini-tp4957969p4957982.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.