[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dsktool.rb and Ruby Questions
On Dec 6, 12:46 am, "Bill Buckels" <bbuck...@mts.net> wrote:
> So if I was to build a project in ruby like dskexplorer.rb that runs in a
> web browser, and my dependencies were properly set, then gem would take care
> of the rest?
>
Yes.
> And does ruby support input forms of some sort? If so would it be possible
> to extend dskexplorer.rb to use dropdown lists and provide a point and click
> interface to dsktool.rb's routines?
There are quite a few full featured web frameworks for ruby that will
make it easy to do web forms development. The most famous one is
called 'ruby on rails', which is very full featured and quite large.
There is another one called 'camping' which is very compact (a single
4k file). Both of these are built on the "model/view/controller"
concept, and may be a bit cryptic if you're not familiar with
structuring your code in that way.
There is also a toolkit called 'shoes' which can be used to develop
native GUI apps (i.e. no need for a browser) but the installer has
some issues running on Vista.
> >I will probably do a new build that fixes the dependancy up.
>
> Is it difficult or does a person just need to untar data and metadata and do
> something with it? Te learning curve would seem to be quite steep. You have
> 464 files in dsktool-0.5.1 To me this is reminiscent of a perl cgi project
> or a tcl application more than a java application, and it also seems that a
absolutely - ruby is a scripting language just like perl or tcl.
> person would need a fountain of knowledge and a well of experience to
> function as a ruby developer. The task of doing anything like this indicates
> a dedicated time investment in ruby. Even to extend what you have done would
> require this. Your project is readable only at a high level for anyone who
> does not know ruby and who is not your equal on disk image formats and file
> systems for these old computers.
Mostly that is because I didn't think enough about extensibility and
readability when I did the
original design for dsktool (it started out as q&d hack I was using to
walk through the DOS 3.3 VTOC to
try and make sense of what I was reading in "Beneath Apple DOS"). When
I decided to do a redesign (which also lead to a renaming since I
didn't want to be tied just to dsk's) I tried to make it easier to get
other people to add support for other platforms. So far I've had one
other person contribute code (Tandy CoCo file system + BASIC
detokenisation) and I believe it was the first ruby code they'd done,
so I think I've had some success there.
>
> So by what you say, dsktool.rb will remain readonly for Apple CP/M disks? Or
> is this case?
>
dsktool.rb does support updating Apple CP/M dsks and also updating DOS
3.3 dsks (along with read only support for ProDOS and Pascal). However
it is no longer being actively developed - when I decided to try and
support platforms other than Apple 2, I rearchitected and renamed it
to ripxplore, and the current ripxplore architecture does not have
support for writing back to images (and making ripxplore read/write is
a lower priority for me than extending the number of platforms, file
systems and native file types it understands).
Regards
Jonno