How to identify which smalltalk IDE/implementation is used by seeing an desktop application developed in smalltalk?
The icons and the lines in the shown widget strongly point towards VisualAge Smalltalk from IBM, which nowadays is VA Smalltalk from Instantiations. The program obviously was generated with a replacement window icon, so that you cannot tell from the window, but the container icon tree displayed here makes me almost 100% sure it is VisualAge.
Do you happen to have access to the runtime directory on that Windows computer? If so, is there a program called abt.exe or nodialog.exe? Or even better: is there one or more of these subdirectories in the runtime directory: \bin \nls \bmp? If so: it is VA.
A picture of the start-up splash screen would help confirm or eliminate some dialects, as would an indication of what OS's it runs on, or the year it was first deployed (is there a copyright statement on the splash screen?). These icons remind me of OS2 or Windows 95 (or Windows 3.1), which would indicate a very early Visual Works or perhaps VSE. Any insight into the source storage mechanism would help too - a .dat file indicates an Envy based system, which would be either early VisualWorks, or VisualAge. Another possible indicator is the icon in the upper left of the window - but the "blue sky/green mountain" in your picture is not one I recognize. VisualAge first had the "eyeball", then later the "Smalltalk balloon" that hearkens back to the 1980 Byte magazine cover. For pictures of some of the older IDEs, look through the older out of print Smalltalk training books at http://stephane.ducasse.free.fr/FreeBooks.html
Related
I've been using smalltalk for a while now and I love the language and the concept. What I just hate is the System browser. This tool doesn't even resemble a modern IDE. How am I supposed to code without tabs, outlines and handy shortcuts? I often find myself implementing a selector and noticing that it would be nice to isolate a piece of code in a separate (private) selector, just for readability shake, but I don't. Because it takes like 5 mouse clicks and I have to navigate away from the selector I am working at, and navigate back to it. Oh wait, I can't! Because it has syntax errors, because I haven't finished it yet! Kills me. And I don't have a 24 inch display to open 3 browsers.
Sorry for a little rant. My question is, is there a real IDE (Eclipse, Net.Beans, VS) for smalltalk? Maybe for some commercial version of smalltalk?
You might want to check out tODE. It's at a very early stage, but it is an attempt to provide a Smalltalk IDE in the web-browser and is a break from the traditional Smalltalk IDE. With that said, I don't think you'd want to start using tODE right away, but you can keep an eye on it as it evolves.
Dale
Pharo is trying to have the Nautilus Browser ready for Pharo
1.4. I suspect there will be a flood of awesome new tools as the system stabilizes over the next few releases.
There's the Glamorous Inspector.
Spoon has been mounted as a WebDAV filesystem, so you can use whatever tool you like. Spoon is not another Smalltalk, but a testbed for revolutionary Smalltalk technology, which can be incorporated into any other Smalltalk (it's currently on top of Squeak)
There is the Tiling Window Manager to help you organize
Since Squeak and Pharo are live, dynamic, open systems powered only by volunteers, anyone sufficiently motivated can create the next generation of tools ;-)
p.s. I feel your pain. The 20-browsers-open thing is a drag. Let's invent the future!
Historically, the real "IDE" is the Smalltalk one, and one could claim that the others are just an adaptation to the limits of traditional textual programming languages (not rethorical, just check out the evolution of typical development environment UIs and how they are adding features that exists in Smalltalk from the very beggining, like the senders and references in VS).
Just a side note: actually more than 2000 open-source projects in the SqueakSource repository were coded without tabs, outlines and shortcuts (I think still in Squeak you can cross reference any text selecting and pressing with Alt-6). I can't tell you how sad I feel when I must to go back to file based developement, still don't understand why most developers love to sweep text, mess with line numbers and page up-down files in directories. The good news for you, is that you have many options:
There is an alternative browser called BobsBrowser (works in Pharo 1.3) which lets you browse
Class hierarchy windows exploring each class
System Category window
Unsaved edits
Recent classes
Recent methods
Method categories for instances and classes
Unsent methods
Driller relating every structural information
etc.
The advantage over the Whisker browser is that the hierarchical lists are attached to a window while in BobsBrowser you can detach them.
It all depends of the different activities you're performing when you're developing. With some experience in Smalltalk you'll find that you prefer some browser for exploratory insights and others for refactorings, etc. BobsBrowser for example is good for knowledge organization or custom navigation of Smalltalk classes and categories, the hierarchies you can see are the organizations from the Smalltalk reflective meta-architecture at any level (classes, senders, implementors), and they are expandable/collapsable (in the classic system browsers you can only expand the system categories and subcategories).
The instance variables were shown historically in the Smalltalk/V flavors, and there is an old goodie (from Squeak 2.7 IIRC) to enable it back again but almost nobody today maintains the classic System Browser in Squeak/Pharo. Adding that feature to OmniBrowser would be more complicated though because is a browser framework (as every serious framework, it took some time to learn it for the first time), although the effort of the Squeak/Pharo community is absolutely incredible, still the Smalltalk community needs more developers.
You have also a commercial Smalltalk which isn't public (downloadable) yet but includes IDE-like features of traditional programming environments
And I don't have a 24 inch display to open 3 browsers.
You could give the Whisker Browser a try. It lays out the methods side-by-side so that you don't have to position all these windows manually.
I played with it a few years ago but I'm not sure what state it's in right now.
I don't know how mature it is, but the Etoile project has an IDE called CodeMonkey for writing Smalltalk applications. It's not specifically for Squeak, and instead uses their own smalltalk implementation, but it may be worth looking into. Unfortunately, it's only available in their SVN repository, so it's a pain to compile and install.
I'm trying to run a program written by someone else in LabVIEW. The program records voltage. However it won't open because it is missing subVIs.
Initially I thought that only one was missing and the rest weren't working becuase they were attached to it but after someone on this forum kindly found it for me the rest of the VIs still won't work so I think I need to download them again. However there are too many off them to get separately, also I tried googling them to no avail.
The subVIs are : Magnet Id, Hardware check, Plot Data and Print, Make Plot Lables, Plot it, Relabel It, Write File header, Record Analog Info, Fix Column Heading, Make Igor Label etc etc (this is not a complete list).
I feel that I should download a DAQ from The National Instruments Website but I am not sure which one. I am using 64 bit LabVIEW 2010 on Windows. Can someone please help me pick out the correct driver?
Thanks!
Just going from memory, those aren't NI VIs that I recognize, especially if the misspellings are in the original.
What hardware is this interfacing with?
You should still be able to open the main VI. It will not compile or run, since the subVIs are missing, but you should be able to open it and maybe get some clues about what it's doing.
The SubVIs all appear to be in the llb file so they should be available. I'm not sure how you can access the subVIs directly from the llb file so you may want to convert this to a project folder (this is the new way of creating libraries since version 8 I think). There are some pages on the NI website that may help, try Converting an LLB to a Project Library and then add this Project Library to your project.
From what I can see the VIs make use of the VISA drivers to communicate with the individual instruments so you should make sure you have this installed. You don't mention what version of LabVIEW 2010 you have but I think they should be provided even the Basic version, I know they are provided with the Professional Development System version.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
I've started programming on Mac OS X in Objective-C and decided to create a little card game. At first I create a command line version. If everything works fine I would like to implement a GUI: Nothing big, just a green window with cards which can be dragged and dropped.
Since I don't have any idea about how to do this: What can I use to implement my card game GUI?
Since Objective-C and Cocoa looks like a "bundle" on Mac OS X, is it possible to use Cocoa for this (and how)? If not, what else should I use or is there already sth. like this?
Regards,
inno
Apple has some sample code here that could point you in the right direction.
This is a fine study in MVC.
Your Model (an active game, player and non-player characters, the cards in the game, etc.) will be entirely in Foundation, at least at first. You can add AppKit-dependent properties such as images later, and use the C preprocessor to conditionalize that code if you want to continue maintaining your command-line program.
Your Controllers will also generally be in pure Foundation. I say “Controllers” because you'll have one for both programs (owning the model, responding to user actions, and running the game—that is, dealing cards, enforcing the rules, etc.), one specifically for the command-line program (holding the readline/output loop), and at least one specifically for the GUI program (owning the game window).
In the GUI app, you'll write your Views with AppKit, of course. In the command-line app, you may want to make a View class, separate from the Controllers, to make it easy to radically change the output quickly (even at runtime, if you want to allow that). Of course, that View will not descend from NSView, and will use terminal output instead of graphical drawing.
I recommend keeping the command-line version of the program alive after you make the GUI version, at least for a little while. You'll know you're doing it right when you can maintain both working versions of the program without much fuss, and even find a bug in one version of the program and fix it in both.
The stage in the Flash CS4 Authoring Enviroment is a running SWF. That what makes thing like the 3D and Bone Tools to work in the IDE.
Is it possible to access that swf ? I suspect the immediate answer would be no because that would raise some security issues maybe and cause lots of developers to crash the IDE every 5 minutes :).
That said I don't expect this to be a straight forward process, but I guess there should be a way to access that.
Any thoughts ?
I can only tell you how components work on the stage, where we've attempted the type of access you talk about.
I suspect that at their core, the 3d and bone tools are implemented using component-like tech to display the "live" stage instance. In general this would involve a compiled instance of a live preview swf that is placed on the stage. It is misleading to think of the stage as a single player. Each component preview runs in its own sandbox that, as far as I can tell, has no means of communication with other component previews on the IDE stage. There is no common storage location.
Of course, if you were in charge of the preview swf (as with the case of a component), you could try LocalConnection to chat, but the previews you want to penetrate are closed. I suspect if you dig hard enough, you'd find the bone/3d preview hidden in the installation folders (perhaps in a swc.. ik.swc looks interesting) and might be able to hack about at it with a decompiler, but straight out the box, I'm not sure there's a solution to what you ask.