Re: [Pharo-users] Pharo 5 and image resizing
On Fri, Aug 19, 2016 at 10:04 AM, p...@highoctane.be wrote: > I've a concern with the image resizing in Pharo 5, as when I'll be loading > several (tons of) packages, MCZs will be piling up and if clearing that > cache isn't going to reduce the size of the image, I am not really keen on > dragging these around. This will just get worse over the course of the > development. > > The image-not-shrinking problem will be solved in the near future, I think that it shouldn't be a big worry if you are starting a new project.
Re: [Pharo-users] Spec > TreeModel: Updating the tree selection after a deletion
Hi Nicolai,
About the rebuilding of the subwidgets, I really don't know. Maybe if I
can force the highlighting I can't ignore the rebuilding issue in some
way, so that's what I'm trying now and seems I'm closer. Do you know how
to make a TreeNodeModel to show itself expanded? I tried with
'#isExpanded: true' and still it doesn't show itself expanded.
Any hint? Any Spec expert attendee in ESUG16 that can spare some minuted
enlightening a newbie?
Cheers,
Offray
On 21/08/16 18:12, Nicolai Hess wrote:
Hi Offrey,
I think one problem is that the tree is always rebuild (on every
selection?)
even with
self needRebuild:false
tree needREbuild: false.
all subwidgets of the notebook (tree and body) are removed and rebuild
from changeBodys call to self buildWithSpecLayout: self class
defaultSpec.
I don't know if this is a bug or unavoidable.
2016-08-18 17:31 GMT+02:00 Offray Vladimir Luna Cárdenas
mailto:offray.l...@mutabit.com>>:
Hi all,
Thanks Nicolai. Your examples helped me to advance and now I have
the basic possibility to modify the tree. The two methods that did
the trick are #addNode and #highlightNextitem, listed below, but I
still get a MNU: receiver of "selectedMorphList is nil, anytime I
try to highlight the next item and even from time to time with
your code example. If you or anyone want to work with the code
directly please install run the playgrounds at [1], [2] & [3],
select any node after running [3] and press the Plus button.
You'll see that nodes are added in the tree after the current
selection, but the recently added node doesn't get the selection
after being created (instead the MNU mentioned before, appears).
I will try to use the new created grafoscopio node and look for
the TreeNodeModel which has this node as a content to get the
highlight.
Help as always is greatly appreciated.
Cheers,
Offray
[1] http://ws.stfx.eu/M5A1F2NPD0QU
[2] http://ws.stfx.eu/EVOY0UKH74L0
[3] http://ws.stfx.eu/5EF0OCUIG7CY
GrafoscopioNotebook>>addNode
tree needRebuild: true.
tree highlightedItem content addNodeAfterMe.
self notebookContent: notebook.
self highlightNextItem.
self buildWithSpecLayout: self class defaultSpec.
GrafoscopioNotebook>>highlightNextItem
| currentItem |
currentItem := tree highlightedItem.
currentItem
ifNotNil: [ | allItems index childrenSize parentNode |
currentItem parentNode
ifNil: [
parentNode := currentItem container.
allItems := parentNode roots ]
ifNotNil: [
parentNode := currentItem parentNode.
allItems := parentNode children value. ].
childrenSize := currentItem content parent children size.
index := allItems indexOf: currentItem.
(index < childrenSize) ifTrue: [
"{allItems . currentItem . index } inspect."
currentItem selected: false.
parentNode
highlightedItem: ((allItems at:(index+1))
selected:true;
takeHighlight;yourself).
]
]
On 11/08/16 13:05, Nicolai Hess wrote:
2016-08-10 21:03 GMT+02:00 Nicolai Hess mailto:nicolaih...@gmail.com>>:
2016-08-10 20:42 GMT+02:00 Nicolai Hess
mailto:nicolaih...@gmail.com>>:
2016-08-10 19:12 GMT+02:00 Nicolai Hess
mailto:nicolaih...@gmail.com>>:
2016-08-10 19:05 GMT+02:00 Offray Vladimir Luna
Cárdenas mailto:offray.l...@mutabit.com>>:
Hi,
I have been fighting with this for several hours
until now. I can't understand how to manage
change on selections on TreeModels with Spec,
which is really frustrating
Here is what I have:
GrafoscopioNotebook>>initializePresenter
tree whenSelectedItemChanged: [ :item |
self updateBodyFor: item.
header whenTextChanged: [ :arg |
(tree selectedItem content header) = arg
ifFalse: [
(tree highlightedItem) content header: arg.
tree roots: tree roots]]]
GrafoscopioNotebook>>updateBodyFor: item
item
ifNotNil: [ self changeBody: item ]
ifNil: [ self inform: 'Nil node' ]
and #changeBody: deals with putting a textual or
code pane according to some tags on the selected
node (and it's wor
Re: [Pharo-users] Google building new OS with Dart
An area that generally interests me is making languages cooperate. When I started with the idea of Pharo using Python libraries, I thought it would take me months to have something usable. Instead it took me weeks mainly because I found that a very simple solution could provide me with a working prototype. So my project Ephestos was born and allowed me to use Pharo to script Blender via Python using sockets , strings, Python execution and some Pharo tricks. It literally blown my mind how easy and simple it was. Of course its far from ideal solution. I have managed to keep most of the Pharo syntax for converting to Python syntax but data is a whole another beast. No complains SmaCC did help a lot there to parse Python dictionaries and lists to Pharo ordered collections. However when another user emailed that he had problems using Ephestos to use the popular Python library Numpy from Pharo, it shown me that there is no such thing as universal solution. After my decision to turn my attention to game development and Unreal game engine, I started learning a lot of C++ and I am wondering what it would take to transpile Pharo code to C++. The difference here is that C++ is no Python , it has a monstrous syntax and is a compiled language. However Pharo already does this with Slang that inherited from Squeak. Slang takes Smalltalk syntax and transpiles it to C. It's mainly used for coding the Pharo VM. C of course is nowhere near as large syntax wise as C++ but at least Slang generates readable code which is my goal. So Pharo is not the isolated island that Smalltalk once was and there is no turning back. There is amber that transpiles Smalltalk to JavaScript, PharoJS that transpiles Pharo to JavaScript and JNIPort that allows Pharo to use Java libraries. So yes it's not that hard if you really want to build a transpiler for Pharo to Dart code and vice versa. On the Subject of OS , Pharo is already a virtual OS. The advantage of virtual OS over regular OS , is that a virtual OS is much simpler in design so easier to hack and play with and also has access to the entire OS it runs on. So in my case what interests me is transpiling Pharo to C++, because that's the language Unreal uses. It will be a challenge but is doable. It would be a big plus for Pharo if it had a powerful transpiler tool that would allow you to convert Pharo code to any language producing readable code. This would allow Pharo access to any project out there. However remember what I said, there are no universal solutions or magic pills. Compromises and sacrifices would have to be made but it's possible. Don't expect others to do it for you, brainstorming and talking about it is far from doing. As Stef wisely says "Pharo is yours" On Thu, 18 Aug 2016 at 07:25, askoh wrote: > It became news a few days ago. It is called Fuchsia and is meant to run on > all devices from IoT on up. The interesting thing is that Dart will be the > main language. The developers promise to make Fuchsia run on Raspberry Pi 3 > shortly. > > Since Dart is pretty close to Smalltalk, how can Smalltalk be the GUI for > Fuchsia? How can it take advantage of Dart VM? Is this an opportunity for > Smalltalk to make an impact? Let's brainstorm. > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: > http://forum.world.st/Google-building-new-OS-with-Dart-tp4911649.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
Re: [Pharo-users] standalone/runtime executable
Pharo has the easiest deployment in any language I have used. It's just a single folder. It does not get any simpler way than that. You can also customize the name of the executable, the icon, the folder and the image itself. There is no need to install Pharo or your Pharo application. So what you are asking yes it would be good for a beginner but someone that has some substantial experience with Pharo it's nowhere near as necessary. Start experimenting you will be suprised how powerful it is. On Thu, 18 Aug 2016 at 11:37, Gour wrote: > Hello, > > there are some Smalltalks like Dolphin, VisualWorks..which can, afaict, > create stand-alone executable for easier deployment to end users. > > I'm aware that Pharo probably has more important tasks to tackle first, > but just curious if creating stand-alone/runtime exectuables is > somewhere on its radar? > > > Sincerely, > Gour > > -- > As a lamp in a windless place does not waver, so the transcendentalist, > whose mind is controlled, remains always steady in his meditation on the > transcendent self. > > > >
Re: [Pharo-users] Keyboard work flow?
The problem is not so much that Pharo has not shortcuts for everything, or that shortcuts are tricky to make or modify. The problem is that Pharo is a very complex environment, more complex than emacs and vim. It's very easy to create messy shortcut setups like emacs and vim. Saying that yes sure it's possible but I do suspect that most Pharo devs are like me, love shortcuts but using mouse is just simpler. Hence why Pharo is no emacs/vim , thank God :D But probably it will require for you to customize and create new shortcuts. After all emacs and vim users use their own personal shortcuts tailor made for their needs. On Sun, 21 Aug 2016 at 23:26, epeld wrote: > Hello! > > Is it possible to get by using ONLY the keyboard in the standard > development > components? > > Here are some workflows that I frequently use and would like to perform > without mouse if possible: > > 1. Use Spotter to browse a class > > 2. Define a new method. That is, allow me to immediately focus the source > code editor so I can start typing a new method > > or > > 1. Use Spotter to browse the implementation of a method > > 2. Edit its source code and accept > > 3. Now recategorize or rename or create new class etc etc. (the problem > here > is that the source code editor will shadow all the shortcuts I normally > have > in the browser, e.g CMD-M CMD-M would normally recategorize the method, but > now this brings up the implementors list instead. > > Thanks! > > > > -- > View this message in context: > http://forum.world.st/Keyboard-work-flow-tp4912091.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
Re: [Pharo-users] standalone/runtime executable
I don't want to present a whole application environment to the user, I want to disable everything not having to do with the task at hand. Also, it gives people with more limited bandwidth connections the options of downloading the entire thing, or a highly stripped version that is much smaller. It certainly makes getting a "build environment" easy when asking for contributions though! Dolphin has a similar tool and is now open source, perhaps there is something there worth investigating for Pharo. I'll check out Phratch (also, Scat is an unfortunately named tool). On Tue, Aug 23, 2016 at 4:26 AM, Dimitris Chloupis wrote: > Pharo has the easiest deployment in any language I have used. It's just a > single folder. It does not get any simpler way than that. You can also > customize the name of the executable, the icon, the folder and the image > itself. There is no need to install Pharo or your Pharo application. > > So what you are asking yes it would be good for a beginner but someone > that has some substantial experience with Pharo it's nowhere near as > necessary. > > Start experimenting you will be suprised how powerful it is. > > On Thu, 18 Aug 2016 at 11:37, Gour wrote: > >> Hello, >> >> there are some Smalltalks like Dolphin, VisualWorks..which can, afaict, >> create stand-alone executable for easier deployment to end users. >> >> I'm aware that Pharo probably has more important tasks to tackle first, >> but just curious if creating stand-alone/runtime exectuables is >> somewhere on its radar? >> >> >> Sincerely, >> Gour >> >> -- >> As a lamp in a windless place does not waver, so the transcendentalist, >> whose mind is controlled, remains always steady in his meditation on the >> transcendent self. >> >> >> >>
Re: [Pharo-users] Keyboard work flow?
Agreed, a mouse is simpler. But a keyboard is faster and (more importantly) ergonomic. I am a bit surprised that you say probably most Pharo devs prefer using the mouse, Dimitris. Being new to Smalltalk, my impression was that the openness of the environment lends itself very well to customization of this sort; context-sensitive shortcuts, custom menus and other utilities tailor made for the specific task at hand. Do people do this or is it preferred to not stray too far from the official releases? Personally, I'm fine with using whatever shortcuts are already there but I would like to be able to add my own when they are missing. In my opinion, most of my workflow issues would be elegantly solved if I could sort of 'shift' keyboard focus to different subcomponents WITHIN a single system window. For example, in the Code Browser, if I could maybe use CTRL-1,2,3,4,5 etc to focus the package, class, category, method and code panels respectively. This would allow me to fire up a Code Browser, find a class, edit the source code, etc using nothing but the keyboard. Tips on how best to implement this are appreciated :) 2016-08-23 13:53 GMT+02:00 Dimitris Chloupis : > The problem is not so much that Pharo has not shortcuts for everything, or > that shortcuts are tricky to make or modify. The problem is that Pharo is a > very complex environment, more complex than emacs and vim. It's very easy > to create messy shortcut setups like emacs and vim. > > Saying that yes sure it's possible but I do suspect that most Pharo devs > are like me, love shortcuts but using mouse is just simpler. Hence why > Pharo is no emacs/vim , thank God :D > > But probably it will require for you to customize and create new > shortcuts. After all emacs and vim users use their own personal shortcuts > tailor made for their needs. > > On Sun, 21 Aug 2016 at 23:26, epeld wrote: > >> Hello! >> >> Is it possible to get by using ONLY the keyboard in the standard >> development >> components? >> >> Here are some workflows that I frequently use and would like to perform >> without mouse if possible: >> >> 1. Use Spotter to browse a class >> >> 2. Define a new method. That is, allow me to immediately focus the source >> code editor so I can start typing a new method >> >> or >> >> 1. Use Spotter to browse the implementation of a method >> >> 2. Edit its source code and accept >> >> 3. Now recategorize or rename or create new class etc etc. (the problem >> here >> is that the source code editor will shadow all the shortcuts I normally >> have >> in the browser, e.g CMD-M CMD-M would normally recategorize the method, >> but >> now this brings up the implementors list instead. >> >> Thanks! >> >> >> >> -- >> View this message in context: http://forum.world.st/ >> Keyboard-work-flow-tp4912091.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>
Re: [Pharo-users] standalone/runtime executable
<> Only if you think deployment means shipping your entire development environment to users and telling them to get on with it. Pharo is absolutely the worst language for deployment in the world. This is why, after all these years, there have only ever been three desktop applications written in it - phratch, dr geo, and the a legal database thing. (i suppose you could be generous and include pharo launcher as well - though that's a bit incestuous). All other applications written in pharo are web apps so deployment is not an issue. There may be good reasons for the lack of attention paid to the deployment of apps but pretending there is no problem is crazy. -- View this message in context: http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Keyboard work flow?
That's the spirit indeed , as a Pharo dev you basically design or improve your development tools. I did not imply that we prefer using only the mouse, obviously if that was true we would not have shortcuts. If memory serves correctly Pharo already offers 217 shortcuts which is a good start (according to the keymap browser you can find in World Menu -> System -> Keymap Browser). Personally when I use GTSpotter I use only shortcuts, when I open the System Browser I use a mix of shortcuts for common actions and mouse for more specific. But yeah I rely a lot on mouse because I work very slow , shortcuts would not be beneficial in my case in terms of speed. If I was working way faster I would have probably used shortcuts a lot more but I prefer to really digest information so using the mouse never becomes an issue in terms of speed but yeah I also use a lot of shortcuts. You can find info about modifying and adding new shortcuts here https://playingwithobjects.wordpress.com/2013/03/19/keymappings-101-for-pharo-2-0/ One thing that Pharo misses is global shortcuts. But even without them you should be able to customize pharo image the easy way. Jump in and do your thing , then nice thing about images is that each image can have diffirent shortcuts so you can create diffirent setups if you want and do all sort of crazy stuff. Also you can always submit your extra shortcuts to be included in a future standard pharo image. I dont think you will get any big complain about it. Just open a case in pharo fogbuz as a new feature and also send a message to the mailing list so we can pay more attention to it. The nice thing about Pharo is that is a very open friendly community so you dont have to fight red tape or large committees like you would in other popular languages to get stuff included or modify pharo in some way. Being small community allows us to be far more agile on these matters. One of the reasons I love using Pharo. On Tue, 23 Aug 2016 at 21:33, Erik Peldan wrote: > Agreed, a mouse is simpler. But a keyboard is faster and (more > importantly) ergonomic. I am a bit surprised that you say probably most > Pharo devs prefer using the mouse, Dimitris. Being new to Smalltalk, my > impression was that the openness of the environment lends itself very well > to customization of this sort; context-sensitive shortcuts, custom menus > and other utilities tailor made for the specific task at hand. Do people do > this or is it preferred to not stray too far from the official releases? > > Personally, I'm fine with using whatever shortcuts are already there but I > would like to be able to add my own when they are missing. > In my opinion, most of my workflow issues would be elegantly solved if I > could sort of 'shift' keyboard focus to different subcomponents WITHIN a > single system window. For example, in the Code Browser, if I could maybe > use CTRL-1,2,3,4,5 etc to focus the package, class, category, method and > code panels respectively. This would allow me to fire up a Code Browser, > find a class, edit the source code, etc using nothing but the keyboard. > Tips on how best to implement this are appreciated :) > > 2016-08-23 13:53 GMT+02:00 Dimitris Chloupis : > >> The problem is not so much that Pharo has not shortcuts for everything, >> or that shortcuts are tricky to make or modify. The problem is that Pharo >> is a very complex environment, more complex than emacs and vim. It's very >> easy to create messy shortcut setups like emacs and vim. >> >> Saying that yes sure it's possible but I do suspect that most Pharo devs >> are like me, love shortcuts but using mouse is just simpler. Hence why >> Pharo is no emacs/vim , thank God :D >> >> But probably it will require for you to customize and create new >> shortcuts. After all emacs and vim users use their own personal shortcuts >> tailor made for their needs. >> >> On Sun, 21 Aug 2016 at 23:26, epeld wrote: >> >>> Hello! >>> >>> Is it possible to get by using ONLY the keyboard in the standard >>> development >>> components? >>> >>> Here are some workflows that I frequently use and would like to perform >>> without mouse if possible: >>> >>> 1. Use Spotter to browse a class >>> >>> 2. Define a new method. That is, allow me to immediately focus the source >>> code editor so I can start typing a new method >>> >>> or >>> >>> 1. Use Spotter to browse the implementation of a method >>> >>> 2. Edit its source code and accept >>> >>> 3. Now recategorize or rename or create new class etc etc. (the problem >>> here >>> is that the source code editor will shadow all the shortcuts I normally >>> have >>> in the browser, e.g CMD-M CMD-M would normally recategorize the method, >>> but >>> now this brings up the implementors list instead. >>> >>> Thanks! >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Keyboard-work-flow-tp4912091.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >
Re: [Pharo-users] standalone/runtime executable
"Only if you think deployment means shipping your entire development environment to users and telling them to get on with it." No Including the Pharo enviroment is a great idea because it makes remote debugging a possibility. Pharo has tools to connect to another running image and control its execution and debugging capabilites which give you the massive advantage of being able to examine bugs up close and personal without the need of the user filling bug reports. You can do this online and offline. Thats the appeal of Pharo anyway. You user can message you and you can connect to his image , fix the error and allow him to continue execution without losing his live data. Try that with you dream deployment tool. Actually its standard practice in deployment when something goes wrong you are basically screwed. Fine grained error correction is not even a question , just stone age uninstall and re install. Hiding the IDE from the user is very simple. I fail to see how Pharo is worse from pretty much every other language that requires installation in order to work when Pharo is just a standalone folder. We must be living in parallel universes. "All other applications written in pharo are web apps so deployment is not an issue." Why you think thats a problem for dekstop apps ? Its actually pretty simple, pharo allows you to create a window or a frame that covers its entire window the moment this happens the user will no longer be able to trigger the world menu, unless he uses shortcuts which can be removed too. This is the approach that PharoLauncher, Phratch and DrGeo follow. The debugger will still trigger in case of error but then you will need a form of error reporting anyway, unless you prefer your pharo app freezing with no error message which obviously is not the standard practice in any dynamic programming language. Sure if you come from C/C++ crash and burn maybe acceptable but is not acceptable for Pharo standards. I suspect it wont be very acceptable for your user either. "There may be good reasons for the lack of attention paid to the deployment of apps but pretending there is no problem is crazy." We read question like this from time to time in the mailing list from beginners but for experienced pharo coder I never read any serious complain. "Also, it gives people with more limited bandwidth connections the options of downloading the entire thing, or a highly stripped version that is much smaller." There are plans to modularize pharo image , there is even an image that offers a minimal set of libraries though its not recommended for general consumption. It can be used as template if size is such a big concern. There is also project Spoon that managed to deploy Squeak (Pharo's ancestor) apps that were down to kbs in size. But smaller you go the more power and flexibility you sacrifice. Suffice to say devs did not care so much about Spoon. Size wise zipped Pharo folder is 30mbs , probably even less if you use 7zip or some other more efficient compression. My connection is 100-200kbs/sec which means it does not take more than 3-4 minutes to download. So I fail to see where is the actual problem. Yeah sure if you are on dial up it will take you forever but then the whole internet will take you forever anyway. People play games that are tens of Gigabytes in size of download and they don't complain about size. This whole get the IDE together with the app is no longer a Smalltalk breakthrough anyway. Python the language I was coding in before porting to Pharo comes with a ton of tools that range from inspectors, debugger, live refactoring tools and even profilers , error reporting tools, testing tools or even manipulation of the syntax itself through the AST module. And this is common for most if not every dynamic language out there. Even games nowadays ship with their own error reporting tools, profilers, anylitics, benchmark tools etc. and of course the usual modding tools. On Tue, Aug 23, 2016 at 10:28 PM kmo wrote: > <> > > Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it. > > Pharo is absolutely the worst language for deployment in the world. This is > why, after all these years, there have only ever been three desktop > applications written in it - phratch, dr geo, and the a legal database > thing. (i suppose you could be generous and include pharo launcher as well > - > though that's a bit incestuous). > > All other applications written in pharo are web apps so deployment is not > an > issue. > > There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy. > > > > > -- > View this message in context: > http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >
Re: [Pharo-users] standalone/runtime executable
Correction: Actually I was wrong, you dont even need to delete shortcuts to make the IDE completely inaccessible to user. The moment you create the morph that covers the Pharo window, that morph can also receive all events which means no Pharo shortcuts will be able to trigger unless of course you make the morph to return the events back to the object that can trigger the IDE tools. And what I am describing here is not some advanced concept this is super basic Pharo development. No magic, nothing special. On Tue, Aug 23, 2016 at 11:31 PM Dimitris Chloupis wrote: > "Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it." > > No > > Including the Pharo enviroment is a great idea because it makes remote > debugging a possibility. Pharo has tools to connect to another running > image and control its execution and debugging capabilites which give you > the massive advantage of being able to examine bugs up close and personal > without the need of the user filling bug reports. You can do this online > and offline. Thats the appeal of Pharo anyway. You user can message you > and you can connect to his image , fix the error and allow him to continue > execution without losing his live data. Try that with you dream deployment > tool. > > Actually its standard practice in deployment when something goes wrong you > are basically screwed. Fine grained error correction is not even a question > , just stone age uninstall and re install. > > Hiding the IDE from the user is very simple. > > I fail to see how Pharo is worse from pretty much every other language > that requires installation in order to work when Pharo is just a standalone > folder. > > We must be living in parallel universes. > > "All other applications written in pharo are web apps so deployment is not > an > issue." > > Why you think thats a problem for dekstop apps ? Its actually pretty > simple, pharo allows you to create a window or a frame that covers its > entire window the moment this happens the user will no longer be able to > trigger the world menu, unless he uses shortcuts which can be removed too. > > This is the approach that PharoLauncher, Phratch and DrGeo follow. > > The debugger will still trigger in case of error but then you will need a > form of error reporting anyway, unless you prefer your pharo app freezing > with no error message which obviously is not the standard practice in any > dynamic programming language. Sure if you come from C/C++ crash and burn > maybe acceptable but is not acceptable for Pharo standards. I suspect it > wont be very acceptable for your user either. > > "There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy." > > We read question like this from time to time in the mailing list from > beginners but for experienced pharo coder I never read any serious > complain. > > "Also, it gives people with more limited bandwidth connections the options > of downloading the entire thing, or a highly stripped version that is much > smaller." > > There are plans to modularize pharo image , there is even an image that > offers a minimal set of libraries though its not recommended for general > consumption. It can be used as template if size is such a big concern. > > There is also project Spoon that managed to deploy Squeak (Pharo's > ancestor) apps that were down to kbs in size. But smaller you go the more > power and flexibility you sacrifice. Suffice to say devs did not care so > much about Spoon. > > Size wise zipped Pharo folder is 30mbs , probably even less if you use > 7zip or some other more efficient compression. My connection is > 100-200kbs/sec which means it does not take more than 3-4 minutes to > download. So I fail to see where is the actual problem. > > Yeah sure if you are on dial up it will take you forever but then the > whole internet will take you forever anyway. People play games that are > tens of Gigabytes in size of download and they don't complain about size. > > This whole get the IDE together with the app is no longer a Smalltalk > breakthrough anyway. > > Python the language I was coding in before porting to Pharo comes with a > ton of tools that range from inspectors, debugger, live refactoring tools > and even profilers , error reporting tools, testing tools or even > manipulation of the syntax itself through the AST module. And this is > common for most if not every dynamic language out there. > > Even games nowadays ship with their own error reporting tools, profilers, > anylitics, benchmark tools etc. and of course the usual modding tools. > > > On Tue, Aug 23, 2016 at 10:28 PM kmo wrote: > >> <> >> >> Only if you think deployment means shipping your entire development >> environment to users and telling them to get on with it. >> >> Pharo is absolutely the worst language for deployment in the world. This >> is >> why, after all these year
Re: [Pharo-users] standalone/runtime executable
2016-08-23 16:26 GMT-03:00 kmo : > <> > > Only if you think deployment means shipping your entire development > environment to users and telling them to get on with it. > > Pharo is absolutely the worst language for deployment in the world. This is > why, after all these years, there have only ever been three desktop > applications written in it - phratch, dr geo, and the a legal database > thing. (i suppose you could be generous and include pharo launcher as well > - > though that's a bit incestuous). > > You forgot to mention PhyloclassTalk which also includes a Windows Installer written in Unicode NSIS. I have two generators for this: A code generator written in Pharo to generate the NSIS script, and an image builder batch script which downloads image from ZeroConf, loads everything through Metacello, and launches NSIS to generate the executable file. I probably do the same for CPack, but now I am busy finishing a paper. You were right in part, deployment in Pharo is not easy and other fashion industry languages perform better, but it is not impossible. > All other applications written in pharo are web apps so deployment is not > an > issue. > > There may be good reasons for the lack of attention paid to the deployment > of apps but pretending there is no problem is crazy. > > I agree with you on this one. We (Smalltalkers) need mountains of self-criticism and slow reading. Hernán
Re: [Pharo-users] Google building new OS with Dart
Kilon: Thanks for your input. That is indeed brainstorming. I know the importance of doing too. But the value of brainstorming is big. A farmer does a lot of work but is not valued much. Watson and Crick brainstormed a lot and discovered the double helix. I don't want Smalltalk to miss that power. Your description of your work and the work of other Smalltalkers shows the amount of work already done. I too have done CAD and Motion Simulation work using VisualWorks, C#, SpaceClaim, Inventor. But there is no killer app or killer use case in all of Smalltalk! How did Python's and Ruby's popularity leapfrog Smalltalk's? How can we get some attention so that we have resources to really grow? China have been widely accused of copying. But I noticed that they have also picked up discarded technologies that are excellent technologies. Examples are solar cells, wind turbines, high speed rail, nuclear power, Alpha chip, MIPS chip, manufacturing, Kylin OS, etc. Perhaps we can make some nation see Smalltalk for the great technology it has for programming productivity. Brainstorming is free speech at its best. Please everyone join. Aik-Siong Koh -- View this message in context: http://forum.world.st/Google-building-new-OS-with-Dart-tp4911649p4912398.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] standalone/runtime executable
<> Only if you think deployment means shipping your entire development environment to users and telling them to get on with it. Pharo is absolutely the worst language for deployment in the world. This is why, after all these years, there have only ever been three desktop applications written in it - phratch, dr geo, and the a legal database thing. (i suppose you could be generous and include pharo launcher as well - though that's a bit incestuous). We are concerned with that aspect. This is not by accident that Guillermo spent 3 years working on bootstrapping a kernel. This is not by accident that Pavel is producing small images. This is not by accident that we want to manage the ***Complete*** image and eco systems with dependencies and that we are fighting with cycles and layers. This is not by accident that we are revisiting all the places that write on disc believing that they can. Now we should probably invest in a solution like the one of Hernan to build application wrapper I think that also having a better abstraction for user deployment is needed. Right now we are working on a bootstrap in production for multiple reason but the main one is to get a clean 'small' kernel so that we can build using normal dependency small applications. If you think that we are going slowly. We are getting slowly and too slow for my taste. I did you analysis back in 2002 :) Now if you want to help us going faster. Help the community fixing bugs. The less other things we have to do the more we can focus. Stef All other applications written in pharo are web apps so deployment is not an issue. There may be good reasons for the lack of attention paid to the deployment of apps but pretending there is no problem is crazy. -- View this message in context: http://forum.world.st/standalone-runtime-executable-tp4911677p4912370.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
