Re: Ann: Luxasm 00.01.00 (2004-04-08)
From: C (blackmarlin_at_asean-mail.com)
Date: 04/16/04
- Next message: Annie: "Re: I feel so deeply hurt."
- Previous message: Andrew Kennedy: "Re: Tasm to Masm code conversion"
- Maybe in reply to: C: "Ann: Luxasm 00.01.00 (2004-04-08)"
- Next in thread: Frank Kotler: "Re: Ann: Luxasm 00.01.00 (2004-04-08)"
- Reply: Frank Kotler: "Re: Ann: Luxasm 00.01.00 (2004-04-08)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 16 Apr 2004 07:30:10 -0700
Frank Kotler <fbkotler@comcast.net> wrote in message news:<407FB2C8.9050707@comcast.net>...
> C wrote:
>
> > Yes, the idea with some of this code is to merge with the IDE so
> > concurrent compilation and highlightling may be done simultanously
> > (as much of the code to do this would be the same)... but this is
> > some way down the line, firstly I want to get Luxasm able to compile
> > itself before the IDE is handled, ideally by someone else as I am
> > only familiar with Motif and I guess we want to be using some other
> > toolkit, which is best is something I cannot decide.
>
> The only thing I've got against Motif is I don't know anything about it.
I will post some NASM examples in the next release (0.1.1) then.
(You will need the GNU lesstif libraries to run them.) The trouble
is that I do not know how to do syntax highlightling with Motif.
In fact I have never seen it done in Motif, so I do not know if it
is even possible using the standard Motif widgets.
> The only thing I know about gtk+ is what I see in Yeoh's examples.
> "gtk_filesel" is the one that sold me.
Where can I find them?
> I think I could figure out how to do all that in "low level style",
> but it would be a pile of work!
Well I would say Xlib direct access _definately_ is _not_ the way to
go, even Xt only would be a pain. The question remains which tool kit
to use, I will look into GTK+ when I have some time -- WxWindows may
also be worth a look. [Though for curiosity's sake examples of how to
access X directly would be interesting.]
[snip]
> May be that we can work "in parallel" on 'em. As Beth observes, we need
> to work out the interfaces between modules before we get too far along.
Yes, anyone want to sketch something out -- I usually use something
vaguly akin to a UML diagram to get my thoughts in order, then use
that to write out the interface / end_interface headers. Of course,
the final result inevitably ends up looking nothing like the original.
I will add some notes / hooks in the parser for how the IDE could
be connected when I can get around to it.
[snip]
> Okay, I have attempted to create something similar. I left out "binary/"
> - I don't think CVS is the best place to distribute binaries...
Yup, seems right.
> Left "insns.dat" out of the "documents/"...
I think all the files worth keeping need renaming and indexing in
that directory anyway.
> I can crib an html version - and/or "info" maybe - for the "user
> docs" directory. I wonder if we should make a "developer docs"
> directory?
I would usually have two directories -- one "notes" and one "format"
for file format documents -- though the latter normally only contains
symbolic links to the ~/files/format directory where I keep the
master copies.
> Stuff like insns.dat, that xsites.html, the ELF spec... Maybe CVS
> isn't the place for that, either.
Probably, as files change in that so ofter -- I commonly use those
directories as temporary dumps anyway.
[snip]
> > Currently I am shoving everything as GNU GPL 2.1 -- as this is one of
> > the more restrictive licenses, things can be relaxed later, eg. the
> > macro library should probably be BSD and the examples public domain.
> > After all it is easier (via copyright law) to relax a restrictive
> > license than to add greater restrictions to public domain. Comments?
>
> TGIANAL, but I would have thought it would work the other way around.
Not really, because you then have versions knocking around with less
restrictive copyrights, which could weaken the copyright of the more
restrictive release. For the other way round, you just re-release.
All that is needed there is the permission of the author, which is not
a problem.
> I figure LuxAsm itself should be plain 'ol GPL - that's what I told SF
> it would be, and we'd need to get permission to change it.
Me too, which is good.
> I don't see that there'd be any objection to the "Library" or
> so-called "Lesser" GPL for the library code.
Objection here: due to the way the LGPL works, applying the LGPL
to a macro library is nearly the same as applying the full GPL.
Either we weaken the LGPL with an additional clause (such as GNAT
has done) or we release the library under BSD -- I think the latter
option would be better because a wrongly worded clause for the
former option could cause the whole LGPL to unravel for the project
and none of use are lawyers.
> I don't know about PD, even for the examples. SF likes a license
> from their "approved" list... BSD or MIT would be okay... MIT's
> *almost* PD... We'll figure something out...
So... we could put the documentation and luxasm source as GPL and
the library plus examples as BSD -- sounds good to me. It is
probably better to only use a couple of licenses anyway, as having
more than that for the project would quickly get confusing.
C
2004-04-16
- Next message: Annie: "Re: I feel so deeply hurt."
- Previous message: Andrew Kennedy: "Re: Tasm to Masm code conversion"
- Maybe in reply to: C: "Ann: Luxasm 00.01.00 (2004-04-08)"
- Next in thread: Frank Kotler: "Re: Ann: Luxasm 00.01.00 (2004-04-08)"
- Reply: Frank Kotler: "Re: Ann: Luxasm 00.01.00 (2004-04-08)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
