- Pharo-dev - lists.pharo.org

[Review: 11536] Add Stream >> printString:

by Max Leske

This issue was more of a discussion between Camillo and Sven. They never reached a conclusion, so please take a look. Iâve compiled the transcript below. The issue isnât easy to solve and maybe we can just close it as ânot importantâ. https://pharo.fogbugz.com/f/cases/11536/Add-Stream-printString ============ Camillo: This method should be added to avoid many asString sends. Example: stream nextPutAll: #('ABC') asString could be written as stream printString: #('ABC'). This is a common extension of the following pattern: stream nextPutAll: #('ABC') printString could be written as stream print: #('ABC'). ============ Sven: And what about #print: as implemented by Transcripts and SocketStreams ? It is shorter. Feels more familiar. ============ Camillo: #print: is already implement and doesn't solve the stream nextPutAll: foo asString case. Since you cannot simply write stream print: foo, since you get quotes added for Strings. Ok, I admit that with decent design you can avoid this, since it should almost never happen that you have a String or a non string object in the same variable, right? ============ Sven: Yeah, that String issue is a bit annoying sometimes. Indeed there is Stream>>#print: already. But look: ThreadSafeTranscript>>#print: anObject self nextPutAll: anObject asString how about that ? There is also #<< whose implementation is even weirder, but it is handy. The question remain: when do you want to mix Strings and other objects as arguments ? ============ Camillo: - #<< is basically a lazy combination of #nextPut: and #nextPutAll: - #print: should call #printOn: on the initial argument, which for strings defaults to storeOn: which I think is wrong, but I would hardly stand a chance changing that :P So my global goal here is to avoid any kind of asString sends while pushing stuff on a stream. Sadly this happens more often than I thought :/ ============ Sven: Maybe this discussion should happen on the mailing list ? Changing String>>#printOn: might be hard, but #<< is much more recent, no ? Could it not be changed to do what you want ? Like Streamm>><< anObject self nextPutAll: anObject asString Another point is that #asString is not so efficient, since it creates throwaway Strings.

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Tudor Girba

Here is how to load and install DBXTalk in Pharo 3.0: Gofer new smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; package: 'ConfigurationOfOpenDBXDriver'; load. #ConfigurationOfOpenDBXDriver asClass loadBleedingEdge. #NBPharoOpenDBX asClass installAsCurrent. Cheers, Doru On Fri, Sep 19, 2014 at 8:45 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeahâ¦ I told you that dbxtalk site information is outdated (and never find > the time to update) > > you need to look here: > > http://smalltalkhub.com/#!/~DBXTalk/Configurations > > (or in the configuration browser) > > cheers, > Esteban > > On 19 Sep 2014, at 08:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > Sebastian, that doesn't look like the correct one > > DBXTalk is on smalltalkhub > > > > https://ci.inria.fr/dbxtalk/ > > > > Stephan > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 19, 2014

Pharo books -> association

by stepharo

Hi guys I wanted to let you know that each time you buy a pharo book the small benefit is given to the association. Stef

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Esteban Lorenzano

yeahâ¦ I told you that dbxtalk site information is outdated (and never find the time to update) you need to look here: http://smalltalkhub.com/#!/~DBXTalk/Configurations (or in the configuration browser) cheers, Esteban On 19 Sep 2014, at 08:00, Stephan Eggermont <stephan(a)stack.nl> wrote: > Sebastian, that doesn't look like the correct one > DBXTalk is on smalltalkhub > > https://ci.inria.fr/dbxtalk/ > > Stephan >

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Stephan Eggermont

Sebastian, that doesn't look like the correct one DBXTalk is on smalltalkhub https://ci.inria.fr/dbxtalk/ Stephan

Sept. 19, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by stepharo

HI martin I'm because this is important to be able to learn Stef On 19/9/14 06:36, Martin McClure wrote: > On 09/15/2014 11:54 AM, Eliot Miranda wrote: > > >> Agreed. But one real problem with the Squeak/Pharo UI is the lack of >> native windows. There is an old project Graphics-External-Ffenestri but >> AFAICT it isn't being used. But there /is/ a really good prototype of a >> native window system above Squeak done by Vassili Bykov in Newspeak. >> The native windows contain morphs, but anything, including MVC, can be >> present. This provides native Win32 Windows (doing other platforms is >> merely work) /and/ the ability to snapshot and bring back up windows on >> a different platform (e.g. open in win32, snapshot and bring up in >> Squeak/Pharo Morphic windows, or vice verse), and the ability to do this >> dynamically. Is anyone motivated to port the Newspeak code back to >> Squeak/Pharo? >> >> >> If you're interested, contact me, or Vassili, or Bob Westergaard and ask >> about Brazil (think plumbing). >> > > By coincidence, this week I dusted off my project (shelved about a > year and a half ago) to port Brazil and Hopscotch to Smalltalk. And > have made some progress, though it's still very early stages. > > If anyone else is interested in helping move this forward more > quickly, let me know... > > Regards, > > -Martin > >

Sept. 19, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by stepharo

Torsten we are 100% in sync on that vision :) Stef > Eliot wrote: >> We're getting there with fast. Tiny needs more definition, but the core Cog/Spur VM on Mac minus plugins and GUI >code is 568k, 506k code, 63k data; the newspeak VM which has fewer primitives but support for two bytecode sets is >453k, 386k code, 68k data. That includes the interpreter, JIT, core primitives and memory manager/GC. Add on >several k for the FFI, C library et al and a VM in a megabyte is realistic. Is that in the right ball park? > Yes, wet's my appetite :) > > Tiny means easy to download and use for scripting, no other dependencies > for the out of the box REPL experience. But still powerfull to built one on another > and scale up to large programs. > > Initially you provide just a simple VM executable for a "tiny smalltalk" (ts), for simple > things like: > > c:\myscripts\ts.exe -e 3+4 > 7 > > where ts.exe is the VM in a few kB including a small initial kernel image (as part of > the PE DATA section). It should be able to run scripts: > > c:\myscripst\ts.exe automate.st > > It should be possible to easily build components (either with or without the sources): > > ts.exe sunit.st -o sunit.sll > ts.exe sunit.st -noSource -o sunit.sll > > So you can either include other scripts > > ts.exe -i sunit.st mytests.st > > or link the previously built binary components to form something new. > > ts.exe -l junit.sll mytests.st > > But it should be possible to build another vm+image easily: > > ts.exe -i mykillerapp.st -o killerapp.exe > or ts.exe -l mykillerapp.sll -o killerapp.exe > > by writing a new PE file for Windows either including a new kernel image or a combined > one based on the already built-in initial kernel of the previous one. > So I can deploy a killerapp or reassemble it to form the next language version. > > SmallScript was very close to that and it was a nice thing to work with. > Especially since usually Smalltalk usually throws things out at the end - but > one never builds a house by carving it out of a rock. We need bricks to assemble. > > With the above scheme you could build components, some of them portable, others > explicitly non-portable as the code includes native calls. The later have to > be rebuilt on the other platform - so if you have good design abstractions you > can implement a UI lib on Windows and one on Mac. > > Some of the components are with the source code packaged in for debugging > (but not changeable), for closed source components you leave it out. > > And still it should support pinnable objects (not moved by GC for callouts), > sandboxing, Classes with UUIDs to allow for side by side loading/migration > and an extensible meta-scheme as this is where Smalltalk is still the hero of all > und metaprogramming will be our future. > > Also the VM should be available as a shared component - so it can run in-process > in other programs like a web browser. Always wished to write: > > <script type="text/tinyscript"> > BrowserLog write: 'HelloWorld'. > </script> > > directly in HTML. > > And this is only the beginning of the wish list... > >> Yep. But personally I think Fuel is better and just as fast. Certainly that's the parcels experience. >> - but still with the ability to bootstrap up to a full saveable image > Yes, Fuel would be an option. At least it would be platform independent. Not sure > about other options (quick loading by mapping component using memory mapped files etc.) > >> This we'll leave to the web framework designers, but it seems eminently doable no? > For sure. > > Bye > Torsten > > >

Sept. 19, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Martin McClure

On 09/15/2014 11:54 AM, Eliot Miranda wrote: > Agreed. But one real problem with the Squeak/Pharo UI is the lack of > native windows. There is an old project Graphics-External-Ffenestri but > AFAICT it isn't being used. But there /is/ a really good prototype of a > native window system above Squeak done by Vassili Bykov in Newspeak. > The native windows contain morphs, but anything, including MVC, can be > present. This provides native Win32 Windows (doing other platforms is > merely work) /and/ the ability to snapshot and bring back up windows on > a different platform (e.g. open in win32, snapshot and bring up in > Squeak/Pharo Morphic windows, or vice verse), and the ability to do this > dynamically. Is anyone motivated to port the Newspeak code back to > Squeak/Pharo? > > > If you're interested, contact me, or Vassili, or Bob Westergaard and ask > about Brazil (think plumbing). > By coincidence, this week I dusted off my project (shelved about a year and a half ago) to port Brazil and Hopscotch to Smalltalk. And have made some progress, though it's still very early stages. If anyone else is interested in helping move this forward more quickly, let me know... Regards, -Martin

Sept. 19, 2014

Re: [Pharo-dev] How production ready is Pharo on SQLServer?

by Sebastian Sastre

For the record, adding some offlist info Iâve got: Here at the bottom there are binaries: http://www.linuxnetworks.de/doc/index.php/OpenDBX/Download#Windows_DLLs And Iâm attaching this screenshot of the problem I saw in a fresh Pharo 3, following the instructions found here: http://dbxtalk.smallworks.com.ar/DBXTalkDrivers/ No stable version for Pharo 3.0, I had the impression that there where people using it in Pharo 3, isnât it? or maybe thatâs an unmaintained repo? trying a dirty hack which tries to load the same of a 2.0 for a 3.0, continues some and then shows this problem: And after trying to remove that startUp line to see how far it can go without that, I found this: And Iâm stuck is that the right repo? suggestions? what should I do? thanks! sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept On Sep 16, 2014, at 11:49 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > I'm trying to follow instructions from here: > http://dbxtalk.smallworks.eu/DBXTalkDrivers/compiling-and-installing-opendb… > > but the link about the binaries for Windows is broken > > suggestions? > > from iPad > > On 12/09/2014, at 17:21, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> ok, I'll try dbx and think of odbc as plan b >> >> from iPad >> >> On 12/09/2014, at 17:14, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: >> >>> DBXTalk is probably right. If it doesn't work, the old ODBC package will work - I have tried that later one (not against SQLServer, but it's just ODBC, so will work). >>> >>> -cbc >>> >>> On Fri, Sep 12, 2014 at 12:37 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> 2014-09-11 17:48 GMT-03:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: >>> > Hi guys, >>> > >>> > there is a project that needs to connect and extend a system using SQLServer >>> > and Pharo is being considered for the backend. >>> > >>> > Just checking, how ready are we for a production-ready backend using Pharo >>> > on SQLServer? >>> >>> (absent) >>> >>> > and how do we connect to it? >>> >>> DBXTalk, probably, but really can't tell. >>> >>> Database connectivity, other than PostgreSQL seems to be rather >>> infrequent, if used at all. >>> >>> >>> Esteban A. Maringolo >>> >>>

Sept. 19, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Andres Valloud

Side comments... Some code just has to be written in C, otherwise you cannot rely on the behavior being correct and ultimately that's a major show stopper for anything you might want to call "production" code. Anything having to do with calling operating system libraries is a typical example of this phenomenon. So, in those cases, translating Smalltalk to C (or interfacing to OS libraries with FFI interfaces) only gives you huge maintenance headaches in the long run. The resulting distractions due to bug reports will obliterate any engineering team's performance, and it's a race that cannot be won as framed. POSIX is there for a reason, let the C compiler do the job it's been doing for 40+ years. But suppose one wants to write C code with Smalltalk syntax anyway. Nevertheless, C99 and newer still apply and one must be aware of the subject matter. The danger is that Smalltalk is so much more user friendly than C, that once one starts writing C in Smalltalk one will never look at the automatically generated C. But is the mechanically generated C code valid? Because if not, then compiling such source code can be no better than "garbage in, garbage out", and then you cannot have production quality. Similar arguments apply to FFI interfaces. Please excuse my ignorance, but I'd like to assume someone's looking into this? What seems to follow is that the architecture of the system should try to minimize the dependencies on external libraries, precisely because the dependencies cause exposure to foreign rules and regulations that slow one down. Creating dependencies in a reasonable manner should be straightforward _for system users_, though. Letting externals create reliable dependencies on one's system should also be facilitated to promote healthy modes of interaction with the community at large. I feel one of our current challenges is to wholeheartedly admit there is no royal road to inventing our future, then act accordingly. Andres.

Sept. 19, 2014