Hello,
Lorenzo raised some issues about text handling in nglStream. Just for record,
let me
start with some implicit design issues in those streams.
nglI/OStream are meant to be higher level than the classical POSIX read(), this
is why
you find a bunch of methods other than Read() in the same scope. We have
choosen to go
as high as we could with full interoperability. The issues :
* For simple C types (ints & floats), we already need to provide a switch (byte
ordering) to keep interoperabity possible. And of course we let the user choose
the
convention, and provide the 'expected' default. While int storage is obvious
(nobody
thought about bit shuffling yet :)), floats are not trivially represented. The
documentation clearly states that NGL will only read and write IEEE754 floating
point
representations. I made sure that the majority of mainstream processors could
do that
(even HPPA Risc and Sun's SPARC), and if we ever found one that would not
support this
format, we would have to implement a software translator.
* String support has also been added in the same scope, because there is a well
established description of what is a 'text file'. We have to provide two
switches for
interoperability (encoding and line ending convention). ReadLine() only assumes
that
parsing till the end of line is handy, which few people would deny I guess.
What is clearly misleading, is that nothing prevents you from mixing calls to
basic
types and string parsing. This is a design compromise, the first nglFile
implementation was splited in nglTextFile and nglBinaryFile with an abstract
nglFile,
consuming a lot of interface and code only to bother the user. It was also
expected
that someone, one day, would try to mix basic types and string parsing.
ReadLine() was provided as a mean to really stream input, ie. read & process
progressively. All human readable text has a very regular apparition of
newlines,
that's why every sane API implements ReadLine(). Side note: when we say 'new
line', it
really writes '\n' when programming in NGL (this is the C lexical convention
for ALL
platforms; MSVC compiler will NOT translate this to \r\n); NGL will take care
of doing
the right conversion from/to file when reading/writing.
Now in the case of a mixed binary/text file, you must obviously explain what is
the
boundary of a string. The current API can't do better than reading through the
next
new line or the end of the file. Otherwise you must go back to the Read()
roots. What
can we do about it ?
a) nglSize ReadText(nglString& rText, nglSize Bytes)
Reads `Bytes' bytes, fill rText using current encoding and line ending
convention
parsing. Returns number of bytes effectively read. This would be the occasion
for
implementing a better ReadText(), the current one based on ReadLine() is safe
but
ineffective.
b) nglSize ReadText(nglString& rText, nglChar Separator)
Reads till `Separator' or end of file. Sadly, this cannot be a generalization of
ReadLine (ie. ReadText(str, '\n')), because of the complex line ending
conversion
code. This thing has to be rearchitected to share some code paths.
Note that the b) case is pretty much hitting the design limit of NGL streams,
we're
starting to cross the helper/protocol boundary. For instance, I wouldn't be
surprised
to be asked to implement ReadText(nglString&, std::list<nglString>
SeparatorSet). And
so on till the full fledge XML parser :). A great part of maintenance is about
explaining that APIs are not marshmallows ...
Other note : I know I can't implement this till next week, and it needs time and
caution; I had a hard time getting ReadLine() correct with all aspects.
Examples/stream must be updated and a better test suite should be set up, else
we'll
still run into bugs 3 months later. Any code is welcome of course, but I rate
this
'tricky' and I'm a bitch about code quality. You've been warned.
Received: from logic.phpwebhosting.com ([66.33.1.213])
by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 1914Yb-0003g8-00
for <[EMAIL PROTECTED]>; Thu, 03 Apr 2003 05:15:05 -0800
Received: (qmail 28985 invoked by uid 508); 3 Apr 2003 13:14:59 -0000
Received: from unknown (HELO FLYER) (212.194.3.122)
by logic.phpwebhosting.com with SMTP; 3 Apr 2003 13:14:59 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] nglStream and text
Organization: Kinopsis
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 3 05:21:27 2003
X-Original-Date: Thu, 3 Apr 2003 15:17:01 +0200
Hehe.. prepare to face my courroux ! :)
This is the usual mumbo jumbo :
ask for a simple thing :
the primary question was :
"why ReadLine is adding (not converting) a /n at the end of my stream
when there is none"
then when it was explained to me that it was a 'feature' :|
"why can't nglStream & nglString relate to each other in a simple way"
aka "where is the nglStream dedicated operator in nglString that anyone
would expect"
and what you get answered is :
<IntentionnalyProvocativeCaricaturePartlyGrabbedFromIrcChatYesterday>
a flood of IEEE and POSIX seasoned political haze trying to say :
"listen darling, what you are asking for is some kind of itchy bitchy
ynooow, and btw I really can't understand why, why ever, you wanna use a
binary file when you can use a text one and automagically workaround the
designed limitations of the wonderfull AND politically correct tool NGL
is... I mean : binary files are... ahem, BAD! ynoooow... for they admit
unreadable proprietary (bad) formats, witch we fight against : not allowing
nglString to output raw data is part of the warfare...
But !!!, since I'm a gentle buddy I might be having a look at this issue by
the end of the year (oops week sorry), so don't hold your breath beacause
there is no way for you to get involved in improving things here... (you
eventually might try to submit something but I warn you : there is no chance
we make this process something sensible and effective)."
</IntentionnalyProvocativeCaricaturePartlyGrabbedFromIrcChatYesterday>
Well..
in ngl I face a missing primitive : think of stream<<str, implemented
from stl to mfc,
If you feel I'm the 'one person that, one day, would try to mix basic
types and string parsing'
(yuck! what an odd attitude.) this is beacause when I asked about -
nglString serialisation - (not text files
parsing) you answered "use the force of ReadLine" not "yeah, nglString
misses an operator".
Btw, I don't have the feeling to ask for a full flegged XML parser here,
I know there is one in NUI
(and meeloo claims it's reeaally neet ;).
So... If you want to talk politics let's talk politics... ;)
Preamble :
Is really '\0' an end of 'Line' construct or rather an end of 'String' one
(witch would imply the end of current line) ?
Manifesto :
- We modern coders need to address binary as well as text files.
- If We modern coders need to exchange data with other application /
environement we shall use a wellknown existing generic exchange format
(say... XML for text files or RIFF for binaries) 'cause we don't bother
reinventing the wheel.
- Then if We modern coders feel we can make a mutch better format intended
for some specific data exchange we specify it, document it, and proudly
promote the use of it.
- Though We modern coders believe that not every single file has a 'format'
(read : specified, documented, and publicly intended for data exchange), we
think of some files as 'local data storage that allows a computer to be
turned off' and believe nobody cares about those files...
- For that purpose modern coders sometimes need to dump data from a struct
or class witch eventually contains an nglString, and be able to read it back
to memory without having to build up a full serialisation subsystem.
- We modern coders, and proud users of high level API's sutch as ngl don't
want to deal with temporary buffers any time a nglString shall be
serialized, as Real coders used to do before the aparition of OO semantics
and data encapsulation concept.
Apendix :
- When we modern coders use some public tool, we DO rely on them provided
that it fullfills the present manifesto or pass the tushang peng untill
eternal oblivion.
- When we modern coders make some public tool, we shall not look in the
users panties and say "ah, too baaad, your thing is hanging along the wrong
leg", but make the tool in order that whatever side it usually bends toward,
it can be used properly.
Hypothesis :
For the purpose of making ngl a - Modern coder complient - tool, I believe
that a string object sutch as nglString needs an appropriate operator :
nglSize nglIStream::Read(nglString&);
nglSize nglOStream::Write(nglString&);
witch would be the correct syntax (relative to streams),
or the reciproque :
nglSize nglString::Recall(nglIStream&);
nglSize nglString::Store(nglOStream&);
witch has the advantage to be completely self-contained (appropriate
management of the resulting boundaries without breaking encapsulation) and
not to clutter nglSteam interface with specialized APIs.
(TTimo : this is where stdio << & >> operators are nice, despite you hate
them, a simple overload inside your object and you've got an iostream
complient object that is sintactically identical to any other primitive
type..., but I wont be that picky for ngl ;)
Statements :
- nglSteam / nglString friendship's only intent is store / recall raw data
to/from the stream.
- nglString knows (and will ever know) about his own boundaries and thus is
fully qualified to store / recall data to/from a stream.
- Since we (as modern coders ;) do rely on ngl, we don't care about what
nglString raw data looks like provided that forth and back serialisation is
possible.
- In the process of recalling raw data from a stream, nglString has some
expectation about the bytes it will recieve, as well as the float operator
would (could this only be a terminating /0 or the pascal way, but whatever
will do).
- If the expectations are not met : data is said "misaligned", and it is
NOT nglString's concern to build an unbreakable file format.
To conclude, I still wait for an example where this would fail or bother ...
Truly yours,
Lo
PS:
If you think that in nglIStream_shr.cpp line 135 you can replace :
rLine += '\n';
by
if(last line character was not '\0') rLine += '\n';
the issue ends here.
btw :
> ReadLine() was provided as a mean to really stream input, ie. read &
process
> progressively.
So why do you Wipe() the target at the begining of each call?
> Hello,
>
> Lorenzo raised some issues about text handling in nglStream. Just for
record, let me
> start with some implicit design issues in those streams.
>
> nglI/OStream are meant to be higher level than the classical POSIX read(),
this is why
> you find a bunch of methods other than Read() in the same scope. We have
choosen to go
> as high as we could with full interoperability. The issues :
>
> * For simple C types (ints & floats), we already need to provide a switch
(byte
> ordering) to keep interoperabity possible. And of course we let the user
choose the
> convention, and provide the 'expected' default. While int storage is
obvious (nobody
> thought about bit shuffling yet :)), floats are not trivially represented.
The
> documentation clearly states that NGL will only read and write IEEE754
floating point
> representations. I made sure that the majority of mainstream processors
could do that
> (even HPPA Risc and Sun's SPARC), and if we ever found one that would not
support this
> format, we would have to implement a software translator.
>
> * String support has also been added in the same scope, because there is a
well
> established description of what is a 'text file'. We have to provide two
switches for
> interoperability (encoding and line ending convention). ReadLine() only
assumes that
> parsing till the end of line is handy, which few people would deny I
guess.
>
> What is clearly misleading, is that nothing prevents you from mixing calls
to basic
> types and string parsing. This is a design compromise, the first nglFile
> implementation was splited in nglTextFile and nglBinaryFile with an
abstract nglFile,
> consuming a lot of interface and code only to bother the user. It was also
expected
> that someone, one day, would try to mix basic types and string parsing.
>
> ReadLine() was provided as a mean to really stream input, ie. read &
process
> progressively. All human readable text has a very regular apparition of
newlines,
> that's why every sane API implements ReadLine(). Side note: when we say
'new line', it
> really writes '\n' when programming in NGL (this is the C lexical
convention for ALL
> platforms; MSVC compiler will NOT translate this to \r\n); NGL will take
care of doing
> the right conversion from/to file when reading/writing.
>
> Now in the case of a mixed binary/text file, you must obviously explain
what is the
> boundary of a string. The current API can't do better than reading through
the next
> new line or the end of the file. Otherwise you must go back to the Read()
roots. What
> can we do about it ?
>
>
> a) nglSize ReadText(nglString& rText, nglSize Bytes)
>
> Reads `Bytes' bytes, fill rText using current encoding and line ending
convention
> parsing. Returns number of bytes effectively read. This would be the
occasion for
> implementing a better ReadText(), the current one based on ReadLine() is
safe but
> ineffective.
>
>
> b) nglSize ReadText(nglString& rText, nglChar Separator)
>
> Reads till `Separator' or end of file. Sadly, this cannot be a
generalization of
> ReadLine (ie. ReadText(str, '\n')), because of the complex line ending
conversion
> code. This thing has to be rearchitected to share some code paths.
>
>
> Note that the b) case is pretty much hitting the design limit of NGL
streams, we're
> starting to cross the helper/protocol boundary. For instance, I wouldn't
be surprised
> to be asked to implement ReadText(nglString&, std::list<nglString>
SeparatorSet). And
> so on till the full fledge XML parser :). A great part of maintenance is
about
> explaining that APIs are not marshmallows ...
>
> Other note : I know I can't implement this till next week, and it needs
time and
> caution; I had a hard time getting ReadLine() correct with all aspects.
> Examples/stream must be updated and a better test suite should be set up,
else we'll
> still run into bugs 3 months later. Any code is welcome of course, but I
rate this
> 'tricky' and I'm a bitch about code quality. You've been warned.
>
>
>
>
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 1918Sw-00051T-00
for <[EMAIL PROTECTED]>; Thu, 03 Apr 2003 09:25:31 -0800
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id 6448DB2DD
for <[EMAIL PROTECTED]>; Thu, 3 Apr 2003 19:25:25 +0200 (CEST)
Received: from 62.4.19.30
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Thu, 3 Apr 2003 19:25:25 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] nglStream and text
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 3 09:31:05 2003
X-Original-Date: Thu, 3 Apr 2003 19:25:25 +0200 (CEST)
There's a lot of issues there, let's try to sort them.
> Is really '\0' an end of 'Line' construct or rather an end of 'String' one
> (witch
> would imply the end of current line) ?
The interpretation of that zero depends on the context. In NGL, it happens to
be the
string terminator for the internal in-memory storage of nglString; the user
does not
have to know about this, only does he need to have GetChars() return a
null-terminated
string, as documented (this is std::string::c_str()). As a design issue,
nglString
does not accept zero as a valid character. This thing is maybe a bad idea,
there are a
lot of thing about nglString implementation that still needs to be discussed.
> If you think that in nglIStream_shr.cpp line 135 you can replace :
>
> rLine += '\n';
>
> by
>
> if(last line character was not '\0') rLine += '\n';
>
> the issue ends here.
This the only other place in NGL where the null character is interpreted for
the user.
It happens that some text protocols use zero as a separator because they need
to be
conservative on all other characters ('find -print0' or [stupid] Flash XML
protocol
for instance). That's why I added the eTextZero case : since it cannot be a
string
character, I could either discard it or interpret it. I chose to interpret it
in the
handiest way.
It would be OK for me to remove this eTextZero item, but we'll have to handle
the
zeroes in another way : the most logical way is to allow embedded zeroes in
nglString.
I'd like to know the status about this in std::string, then the UTF-8's opinion
(because I want to go UTF-8) and we should be set.
> For the purpose of making ngl a - Modern coder complient - tool, I believe
> that a
> string object sutch as nglString needs an appropriate operator :
> nglSize nglIStream::Read(nglString&);
> nglSize nglOStream::Write(nglString&);
> witch would be the correct syntax (relative to streams),
> or the reciproque :
> nglSize nglString::Recall(nglIStream&);
> nglSize nglString::Store(nglOStream&);
You're asking for serialization support, and we did not understood that from the
beginning. In this case, we setup an arbitrary convention per serializable
object, and
as long as there are Store and Recall methods, it can stay internal and
undocumented.
I'm fine with these concepts. However ...
There is not a trace of serialization support in NGL, and I intend it to be
that way.
Let me explain further :
- The Read/Write/Intxx/float are basic necessities for binary access, and fill
the C++
gap which stupidly cannot treat basic types as objects (hence we can't overload
float::Store). I don't call this 'serialization' at all, however it's cleary
the basis
support for what a real OO geek would call serialization.
- I have plenty experience on serialization, with C++ and other language (PHP),
including a very large scale project (NeL). I have a bunch of very good and live
reasons not to include serialization right into NGL.
- Now, as said earlier, I'm fine with serialization concepts and people who
want to
use it. I'd be happy to see a libnglserialize companion project happening. I'd
be
willing to help. But as a maintainer of NGL, I don't put one finger in this
machine,
see previous item.
> (TTimo : this is where stdio << & >> operators are nice, despite you hate
> them, a
> simple overload inside your object and you've got an iostream complient
> object that
> is sintactically identical to any other primitive type..., but I wont be that
> picky
> for ngl ;)
The << and >> operators are syntactic sugar. You can setup any other convention
for
'store' and 'load' and be consistent with it, however this is STL's convention.
The
most important fact, is that you can't write decent programs with these
operators :
you cannot check errors nor partial read/write (besides heavyweight exception
handling). And I've never seen a serialization implementation that made this
error
checking facultative. I've actually seen all of them miserably fail.
Meeloo and I are getting less and less religious about syntactic battles, most
of our
goals are doing the thing right before making it look cool. When it's only cool
and is
not right, it's definitively not a fit.
Now, this is the design choices and political believes of NGL maintainers that
were
explained to you. This is not going from nowhere to nowhere, NGL has been
driven by
different interests (including commercial ones) in 3 years, and it has explored
a lot
of different ways and use cases. I've also quite an experience on maintenance,
and
I've choosen to put quality expectations on a high level, and hence the entry
level is
also high. It's not the first time people are pissed that I don't plug in NGL
the
simplest ideas, but they often forget than they can still implement it by
themselves.
If they're on the right direction, this will only make their point stronger. And
remember I'm really willing to do anything in NGL that will support your goal,
but not
necessarily implement your goals. Tell me if something is lacking for
serialisation
support.
> btw :
>> ReadLine() was provided as a mean to really stream input, ie. read &
> process
>> progressively.
>
> So why do you Wipe() the target at the begining of each call?
If I didn't call Wipe(), the method would not work as advertised. Then the
question is
'why ReadLine() works that way' ? There is documentation, and examples
scattered all
around in NGL and NUI, your turn to explain me why it should work otherwise.
Received: from logic.phpwebhosting.com ([66.33.1.213])
by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 191CaF-00008c-00
for <[EMAIL PROTECTED]>; Thu, 03 Apr 2003 13:49:19 -0800
Received: (qmail 6902 invoked by uid 508); 3 Apr 2003 21:49:12 -0000
Received: from unknown (HELO FLYER) (212.194.3.122)
by logic.phpwebhosting.com with SMTP; 3 Apr 2003 21:49:12 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] nglStream and text
Organization: Kinopsis
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 3 13:52:09 2003
X-Original-Date: Thu, 3 Apr 2003 23:51:14 +0200
> As a design issue, nglString
> does not accept zero as a valid character. This thing is maybe a bad idea,
there are a
> lot of thing about nglString implementation that still needs to be
discussed.
> It would be OK for me to remove this eTextZero item, but we'll have to
handle the
> zeroes in another way : the most logical way is to allow embedded zeroes
in nglString.
well ngl appears to be a C++ (should i say C+ ?) and thus using an inherited
C environnement, this would cut nglString from being assigned with a char*
:/
> I'd like to know the status about this in std::string, then the UTF-8's
opinion
> (because I want to go UTF-8) and we should be set.
sounds reasonable...
> You're asking for serialization support, and we did not understood that
from the
> beginning.
At last ...
> There is not a trace of serialization support in NGL, and I intend it to
be that way.
> Let me explain further :
>
> - The Read/Write/Intxx/float are basic necessities for binary access, and
fill the C++
> gap which stupidly cannot treat basic types as objects (hence we can't
overload
> float::Store). I don't call this 'serialization' at all, however it's
cleary the basis
> support for what a real OO geek would call serialization.
> Tell me if something is lacking for serialisation support.
yep! precisely : nglString::Store/Recall... nothing more.. and fill the C
gap which stupidly cannot treat strings as basic types.. ;)
> - I have plenty experience on serialization, with C++ and other language
(PHP),
> including a very large scale project (NeL). I have a bunch of very good
and live
> reasons not to include serialization right into NGL.
I'll be glad you share some experience here..
> - Now, as said earlier, I'm fine with serialization concepts and people
who want to
> use it. I'd be happy to see a libnglserialize companion project happening.
I'd be
> willing to help. But as a maintainer of NGL, I don't put one finger in
this machine,
> see previous item.
libnglserialize wouldn't live without a nglSerialisable interface (witch
would be a BAD thing inside nglString for we modern coders have taken the
habit not to code virtualz in basic objects) and will never be a companion
if you don't make a little room for it.... but you might have an alternative
patern handy?
> The << and >> operators are syntactic sugar.
> you cannot check errors nor partial read/write (besides heavyweight
exception
Yep... we all know that.. ;)
> It's not the first time people are pissed that I don't plug in NGL the
> simplest ideas, but they often forget than they can still implement it by
themselves.
but this is more a design issue than an effort one, I've spent mutch more
time writing a silly/dramatic mail than I would have writing a wrapper
serialisable class for nglString ... that's my way of getting involved here
if not another ...
Rrreealy Yours
Lo.
Received: from logic.phpwebhosting.com ([66.33.1.213])
by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 191OiK-0000lM-00
for <[EMAIL PROTECTED]>; Fri, 04 Apr 2003 02:46:28 -0800
Received: (qmail 10373 invoked by uid 508); 4 Apr 2003 10:46:19 -0000
Received: from unknown (HELO FLYER) (212.194.46.153)
by logic.phpwebhosting.com with SMTP; 4 Apr 2003 10:46:19 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Organization: Kinopsis
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [NGL-devel] "bridging the C gap that stupidly cannot treat strings as
basic types"... nglString overload receptacle
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 4 02:47:15 2003
X-Original-Date: Fri, 4 Apr 2003 12:48:21 +0200
I had a look to the eventuality of a 'serializable wrapper class' for nglString
this morning,
and there are a couple of issues that prevent nglString to be overloaded
reasonably :
To be as compact & efficient as it could, the only methods a wrapper class
would need to duplicate are the constructors
and the operators that can't be inherited, all other methods would be provided
by nglString itself.
and that woud be +/- 20mn work .... :)
BUT !
There is still a problem regarding the return type of nglString's methods witch
are legitimately nglString and
references to (when not other)... then at bootstrapping time, it will fail when
in reference context :
ie:
nglSerialiszableString str = "write something kewl"; // a wrappers instance
void ProcessString(nglSerialiszableString &_str); // some reference asking
function proto
try :
ProcessString(str.Extract(6)); // fails beacause of incompatible return type...
A naïve solution would be to duplicate every single method with appropriate
conversion for references to 'this' or
reinstanciating when a full object is returned.. :/ sounds terrible...
So I thought of a method that would permit the insertion of serialisation
mechanism in ngl without requiring a virtual
interface, keeping all privates you like to etc... It is derived from the
method is use for some strucural (templated)
patterns in sphere... (would be a general overload bootstrap thing but let's
stay on focus)
That is : replace all occurences of nglString inside nglString to a class
template parameter defaulting to nglString.
et voila....
it won't change anything for the actual use of nglString and will allow a
subclass to do the following
class Whatever : public nglString<Whatever>
{
.... etc.
it solves the internal / return type pb,
but (since nglString isn't a 'pure' template class) it needs one more little
trick regarding implementation and overload
type definition :
#if defined(NGLSTRING_OVERLOAD_INCLUDE)
#include NGLSTRING_OVERLOAD_INCLUDE
#endif
witch forces the overload to be unique (might not be that bad afterall)...
I believe there is no major caveat with this method (if you see some tell me),
and it's quite transparent to the actual
design (it won't answer the zero's status issue though ;). Anyway it might
sound a little odd to you (making nglString a
design singularity in ngl).
This said, as long as serialisation is concerned, I believe it would be
muuuutch simpler to simply provide some store /
recall methods, being the only ones provided in ngl, and that would give some
sort 'basic type' status to nglString
concerning relation to streams.
Serializably yours
Lo.
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 191R3P-0003Cc-00
for <[EMAIL PROTECTED]>; Fri, 04 Apr 2003 05:16:23 -0800
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id 74B0CAFAD
for <[EMAIL PROTECTED]>; Fri, 4 Apr 2003 15:16:15 +0200 (CEST)
Received: from 62.4.19.30
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Fri, 4 Apr 2003 15:16:15 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] serialization
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 4 05:17:04 2003
X-Original-Date: Fri, 4 Apr 2003 15:16:15 +0200 (CEST)
Lorenzo Pastrana said:
>
> I had a look to the eventuality of a 'serializable wrapper class' for
> nglString this
> morning, and there are a couple of issues that prevent nglString to be
> overloaded
> reasonably :
You didn't ask what where my 'bunch of reasons' to loathe serialization, but
you just
bumped into a few I had. I'm fine with serialization as long as it's kept as an
independent problem from NGL implementation issues. Pro-serializers can then
have fun
and run by themselves into their own problems without having me to say 'I told
you'
:).
Let's go back to the very beginning : you want to serialize ? I want this task
to
implemented as independently as NGL as possible ? They are solutions, here is
one :
class nglISerializer
{
nglISerializer(nglIStream& rInput);
operator <<(int x);
operator <<(const nglString&);
operator <<(whatever thing you want to serialize);
};
And the same for nglOSerializer. Easy to use, STL syntax compliant, extensible,
orthogonal with NGL. If you can imagine that "objects can serialize to a
stream" and
"streams can serialize objects" are the same concept, you're done.
Received: from logic.phpwebhosting.com ([66.33.1.213])
by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 191SG6-0005Rl-00
for <[EMAIL PROTECTED]>; Fri, 04 Apr 2003 06:33:34 -0800
Received: (qmail 29754 invoked by uid 508); 4 Apr 2003 14:33:23 -0000
Received: from unknown (HELO FLYER) (212.194.46.153)
by logic.phpwebhosting.com with SMTP; 4 Apr 2003 14:33:23 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]>
Subject: Re: [NGL-devel] serialization
Organization: Kinopsis
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 4 06:35:24 2003
X-Original-Date: Fri, 4 Apr 2003 16:35:26 +0200
> You didn't ask what where my 'bunch of reasons' to loathe serialization, but
> you just
> bumped into a few I had.
This was very-not a general serialisation problem !
It is related to the specific status of nglString and the grey zone it stands
upon you say it's black I say it's
white...
Well keep nglString a non-overloadable non-stream-readable class i'll stick to
my helper functions ...
Nobody will say I didn't try.. :/
This is ground control, end of nglString transmission ROGER.
> class nglISerializer
> {
> nglISerializer(nglIStream& rInput);
>
> operator <<(int x);
> operator <<(const nglString&);
> operator <<(whatever thing you want to serialize);
> };
This is typically the kind of design I try to avoid ...
-> every time you make a single move you keep on updating classes and classes,
where your move needs to be aknowledged,
making every next move a little heavyer and error prone ... untill you don't
make no move at all.
btw an object could need to serialize private data ...
So I tend to be a little more 'structural' than 'exhaustive' mainly using
interfaces, of course they have theyr
limitations (typically in nglString kind of situation) but i'd like this one
better :
class nglSerialisable
{
public:
virtual nglSize Serialise(nglIStream& rArchive) = 0;
virtual nglSize Serialise(nglOStream& rArchive) = 0;
};
... Self contained, opaque (can be used in a 'memento' pattern for undo/redo,
macros record/playback), but also this is
why some types, where the interface won't fit, need to be natively streamables.
Cheers.
Lo.
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 191SY0-00006V-00
for <[EMAIL PROTECTED]>; Fri, 04 Apr 2003 06:52:05 -0800
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id 23FE8AFAD
for <[EMAIL PROTECTED]>; Fri, 4 Apr 2003 16:52:00 +0200 (CEST)
Received: from 192.168.1.3
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Fri, 4 Apr 2003 16:52:00 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] serialization
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 4 06:53:22 2003
X-Original-Date: Fri, 4 Apr 2003 16:52:00 +0200 (CEST)
Could we go on with this on monday ? I'm catching a train in 45min, and I'm off
in the
mountains these next two days.
Have a nice WE!
Received: from logic.phpwebhosting.com ([66.33.1.213])
by sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian))
id 191Ss3-0004Fx-00
for <[EMAIL PROTECTED]>; Fri, 04 Apr 2003 07:12:47 -0800
Received: (qmail 6450 invoked by uid 508); 4 Apr 2003 15:12:36 -0000
Received: from unknown (HELO FLYER) (212.194.46.153)
by logic.phpwebhosting.com with SMTP; 4 Apr 2003 15:12:36 -0000
Message-ID: <[EMAIL PROTECTED]>
From: "Lorenzo Pastrana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Subject: Re: [NGL-devel] serialization
Organization: Kinopsis
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 4 07:14:44 2003
X-Original-Date: Fri, 4 Apr 2003 17:14:39 +0200
> Could we go on with this on monday ? I'm catching a train in 45min, and I'm
> off in the
> mountains these next two days.
Hehe happy you..
> Have a nice WE!
Toi meme ! ;)
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 1932v9-0000LA-00
for <[EMAIL PROTECTED]>; Tue, 08 Apr 2003 16:54:31 -0700
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id F41CDB6FB
for <[EMAIL PROTECTED]>; Wed, 9 Apr 2003 01:54:30 +0200 (CEST)
Received: from 192.168.1.3
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Wed, 9 Apr 2003 01:54:31 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_20030409015431_83559"
Subject: [NGL-devel] nglInputDevice proposal
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Tue Apr 8 16:55:07 2003
X-Original-Date: Wed, 9 Apr 2003 01:54:31 +0200 (CEST)
------=_20030409015431_83559
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
One of the last thing of the TODO's pending tasks was reviving the input device
support, aka joystick and such. Here is a header losely based on the nglInput.h
in CVS
:
* renamed nglInput to less ubiquitous nglInputDevice (this is getting crowded,
70
classes in NGL !)
* removed input type enum, added the more versatile GetName() string : as long
as
sensible keywords are in there, that's cool. The Linux input driver sends pretty
accurate 'device model' strings (even for non-USB), all the better. It's easy to
generate a '%d axis, %d buttons joystick' or 'tablet' name a fallback.
* added GetPort() which should contain anything useful to physically locate the
joystick. This is mostly needed for game configuration saving, where user
prefer to
configure binding for whatever is connected on 'game port 1' (à la
Atari/Amiga). It's
of course also possible to save bindings relative to a specific device using
GetName()
(unless two identical devices are plugged). To be adjusted for every platform
and each
API, the output must only be reproductible.
* nglInputDevice is actually a proxy to a nglInputDeviceInstance class. Ref
counting
had to be used somewhere (at least for Linux), this way it is transparent and
we just
have to tell user to delete objects returned by Enum() when they don't want
them. It
also allows me to cope with multiple APIs easily (XInput, Linux input, and
legacy
joystick interface + FreeBSD variant), in my case nglInputDevice can hide
several
nglInputDeviceIntance-based implementations.
* nglInputDeviceInstance is an internal class representing a physical device.
The
Linux implementation can heritate both from this and nglEvent for a convenient
device
node access.
* I removed IsConnected(), instead Update() returns false if the device is
not/no more
present. We can have nglInputDevice object that represent input devices no
longer
valid, that is also where the ref'counting is handy (again, true for Linux :)).
* This simple test works well here with my sample Linux joystick implementation
:
while ((dev = nglInputDevice::Enum(i++))) {
dev->Dump();
delete dev;
}
------=_20030409015431_83559
Content-Type: application/octet-stream; name="nglInputDevice.h"
Content-Disposition: attachment; filename="nglInputDevice.h"
Content-Transfer-Encoding: base64
LyoKICBOR0wgLSBDKysgY3Jvc3MtcGxhdGZvcm0gZnJhbWV3b3JrIGZvciBPcGVuR0wgYmFzZWQg
YXBwbGljYXRpb25zCiAgQ29weXJpZ2h0IChDKSAyMDAwLTIwMDMgTkdMIFRlYW0KCiAgVGhpcyBs
aWJyYXJ5IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgog
IG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJs
aWMKICBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
OyBlaXRoZXIKICB2ZXJzaW9uIDIuMSBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KCiAgVGhpcyBsaWJyYXJ5IGlzIGRpc3RyaWJ1dGVkIGluIHRo
ZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZ
OyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKICBNRVJDSEFOVEFCSUxJVFkg
b3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQogIExlc3Nl
ciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCgogIFlvdSBzaG91bGQg
aGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMKICBM
aWNlbnNlIGFsb25nIHdpdGggdGhpcyBsaWJyYXJ5OyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVl
IFNvZnR3YXJlCiAgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAs
IEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQoqLwoKLyohClxmaWxlICBuZ2xJbnB1dERldmlj
ZS5oClxicmllZiBJbnB1dCBkZXZpY2VzIGludGVyZmFjZSAobm90IG1vdXNlIG9yIGtleWJvYXJk
KQoqLwoKI2lmbmRlZiBfX25nbElucHV0RGV2aWNlX2hfXwojZGVmaW5lIF9fbmdsSW5wdXREZXZp
Y2VfaF9fCgojaW5jbHVkZSAibmdsLmgiCiNpbmNsdWRlICJuZ2xTdHJpbmcuaCIKCgovLyEgSW5w
dXQgZGV2aWNlcyBpbnRlcmZhY2UKLyohCkZJWE1FCiAqLwpjbGFzcyBuZ2xJbnB1dERldmljZQp7
CnB1YmxpYzoKICAvKiogQG5hbWUgRW51bWVyYXRpb24gKi8KICAvL0B7CiAgc3RhdGljIG5nbElu
cHV0RGV2aWNlKiBFbnVtICh1aW50IEluZGV4KTsKICAvL0B9CgogIC8qKiBAbmFtZSBMaWZlIGN5
Y2xlICovCiAgLy9AewogIHZpcnR1YWwgfm5nbElucHV0RGV2aWNlKCk7CiAgLy9AfQoKICAvKiog
QG5hbWUgU3RhdHVzIHBvbGxpbmcgKi8KICAvL0B7CiAgYm9vbCAgICAgIFVwZGF0ZSgpOwogIG5n
bFN0cmluZyBHZXRQb3J0KCk7CiAgbmdsU3RyaW5nIEdldE5hbWUoKTsKICB1aW50ICAgICAgR2V0
QnV0dG9uQ291bnQoKTsKICBib29sICAgICAgR2V0QnV0dG9uU3RhdGUgKHVpbnQgSW5kZXgpOwog
IHVpbnQgICAgICBHZXRBeGVDb3VudCgpOwogIGZsb2F0ICAgICBHZXRBeGVWYWx1ZSAodWludCBJ
bmRleCk7CiAgdm9pZCAgICAgIER1bXAgKGludCBMZXZlbCA9IDApIGNvbnN0OwogIC8vQH0KCnBy
aXZhdGU6CiAgY2xhc3MgbmdsSW5wdXREZXZpY2VJbnN0YW5jZSogbXBEZXZpY2U7CgogIG5nbElu
cHV0RGV2aWNlKGNsYXNzIG5nbElucHV0RGV2aWNlSW5zdGFuY2UqIHBEZXZpY2UpOwoKICBmcmll
bmQgY2xhc3MgbmdsSW5wdXREZXZpY2VJbnN0YW5jZTsKfTsKCiNlbmRpZiAvLyBfX25nbElucHV0
RGV2aWNlX2hfXwo=
------=_20030409015431_83559
Content-Type: application/octet-stream; name="nglInputDeviceInstance.h"
Content-Disposition: attachment; filename="nglInputDeviceInstance.h"
Content-Transfer-Encoding: base64
LyoKICBOR0wgLSBDKysgY3Jvc3MtcGxhdGZvcm0gZnJhbWV3b3JrIGZvciBPcGVuR0wgYmFzZWQg
YXBwbGljYXRpb25zCiAgQ29weXJpZ2h0IChDKSAyMDAwLTIwMDMgTkdMIFRlYW0KCiAgVGhpcyBs
aWJyYXJ5IGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vcgog
IG1vZGlmeSBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJs
aWMKICBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
OyBlaXRoZXIKICB2ZXJzaW9uIDIuMSBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KCiAgVGhpcyBsaWJyYXJ5IGlzIGRpc3RyaWJ1dGVkIGluIHRo
ZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCiAgYnV0IFdJVEhPVVQgQU5ZIFdBUlJBTlRZ
OyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKICBNRVJDSEFOVEFCSUxJVFkg
b3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQogIExlc3Nl
ciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCgogIFlvdSBzaG91bGQg
aGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJsaWMKICBM
aWNlbnNlIGFsb25nIHdpdGggdGhpcyBsaWJyYXJ5OyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVl
IFNvZnR3YXJlCiAgRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAs
IEJvc3RvbiwgTUEgIDAyMTExLTEzMDcgIFVTQQoqLwoKI2lmbmRlZiBfX25nbElucHV0RGV2aWNl
SW5zdGFuY2VfaF9fCiNkZWZpbmUgX19uZ2xJbnB1dERldmljZUluc3RhbmNlX2hfXwoKI2luY2x1
ZGUgIm5nbC5oIgojaW5jbHVkZSAibmdsSW5wdXREZXZpY2UuaCIKI2luY2x1ZGUgPHZlY3Rvcj4K
CgpjbGFzcyBuZ2xJbnB1dERldmljZUluc3RhbmNlCnsKcHVibGljOgogIG5nbFN0cmluZyAgICAg
ICAgICBQb3J0OwogIG5nbFN0cmluZyAgICAgICAgICBOYW1lOwogIHN0ZDo6dmVjdG9yPGZsb2F0
PiBBeGVzOwogIHN0ZDo6dmVjdG9yPGJvb2w+ICBCdXR0b25zOwoKICBzdGF0aWMgbmdsSW5wdXRE
ZXZpY2UqIENyZWF0ZURldmljZShuZ2xJbnB1dERldmljZUluc3RhbmNlKiBtcERldmljZSk7Cgog
IG5nbElucHV0RGV2aWNlSW5zdGFuY2UoKTsKICB2aXJ0dWFsIH5uZ2xJbnB1dERldmljZUluc3Rh
bmNlKCk7CgogIHZpcnR1YWwgYm9vbCBVcGRhdGUoKTsKCiAgdm9pZCBJbmNSZWYoKTsKICB2b2lk
IERlY1JlZigpOwoKcHJpdmF0ZToKICB1aW50IG1SZWZDbnQ7Cn07CgojZW5kaWYgLy8gX19uZ2xJ
bnB1dERldmljZUluc3RhbmNlX2hfXwo=
------=_20030409015431_83559--
Received: from relay-1v.club-internet.fr ([194.158.96.112])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 193CJ0-0006b6-00
for <[EMAIL PROTECTED]>; Wed, 09 Apr 2003 02:55:46 -0700
Received: from meeloo.net (f12v-10-204.d1.club-internet.fr [213.44.181.204])
by relay-1v.club-internet.fr (Postfix) with ESMTP id 5BABD16AC
for <[EMAIL PROTECTED]>; Wed, 9 Apr 2003 11:55:10 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Sebastien Metrot <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] nglInputDevice proposal
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Wed Apr 9 02:57:04 2003
X-Original-Date: Wed, 09 Apr 2003 11:54:56 +0200
I'd add :
nglString GetButtonName(uint i);
nglString GetAxeName(uint i);
Any reason why some attributes are public?
Otherwise it's ok for me.
MeeLoo
Vincent Caron wrote:
>One of the last thing of the TODO's pending tasks was reviving the input device
>support, aka joystick and such. Here is a header losely based on the
>nglInput.h in CVS
>:
>
>* renamed nglInput to less ubiquitous nglInputDevice (this is getting crowded,
>70
>classes in NGL !)
>
>* removed input type enum, added the more versatile GetName() string : as long
>as
>sensible keywords are in there, that's cool. The Linux input driver sends
>pretty
>accurate 'device model' strings (even for non-USB), all the better. It's easy
>to
>generate a '%d axis, %d buttons joystick' or 'tablet' name a fallback.
>
>* added GetPort() which should contain anything useful to physically locate the
>joystick. This is mostly needed for game configuration saving, where user
>prefer to
>configure binding for whatever is connected on 'game port 1' (à la
>Atari/Amiga). It's
>of course also possible to save bindings relative to a specific device using
>GetName()
>(unless two identical devices are plugged). To be adjusted for every platform
>and each
>API, the output must only be reproductible.
>
>* nglInputDevice is actually a proxy to a nglInputDeviceInstance class. Ref
>counting
>had to be used somewhere (at least for Linux), this way it is transparent and
>we just
>have to tell user to delete objects returned by Enum() when they don't want
>them. It
>also allows me to cope with multiple APIs easily (XInput, Linux input, and
>legacy
>joystick interface + FreeBSD variant), in my case nglInputDevice can hide
>several
>nglInputDeviceIntance-based implementations.
>
>* nglInputDeviceInstance is an internal class representing a physical device.
>The
>Linux implementation can heritate both from this and nglEvent for a convenient
>device
>node access.
>
>* I removed IsConnected(), instead Update() returns false if the device is
>not/no more
>present. We can have nglInputDevice object that represent input devices no
>longer
>valid, that is also where the ref'counting is handy (again, true for Linux :)).
>
>* This simple test works well here with my sample Linux joystick
>implementation :
>
> while ((dev = nglInputDevice::Enum(i++))) {
> dev->Dump();
> delete dev;
> }
>
>
>
>
Received: from smtp-102-tuesday.nerim.net ([62.4.16.102] helo=kraid.nerim.net)
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 193DmS-0003Zu-00
for <[EMAIL PROTECTED]>; Wed, 09 Apr 2003 04:30:16 -0700
Received: from zerodeux.net (mksp.net2.nerim.net [62.4.19.30])
by kraid.nerim.net (Postfix) with ESMTP id 02A9C40F48
for <[EMAIL PROTECTED]>; Wed, 9 Apr 2003 13:30:12 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Vincent Caron <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226
Debian/1.2.1-9
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] nglInputDevice proposal
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Wed Apr 9 04:31:04 2003
X-Original-Date: Wed, 09 Apr 2003 13:30:12 +0200
Sebastien Metrot wrote:
> I'd add :
> nglString GetButtonName(uint i);
> nglString GetAxeName(uint i);
How can we fill these ? I can't do better than 'axis %d' and 'button %d'
for Linux, what is the state for other APIs ?
> Any reason why some attributes are public?
They are public but in a private class (this header is internal, namely
in src/input/), this way we don't have to code the Get/Set accessors for
every field. The NGL user does not know about nglInputDeviceInstance.
Received: from relay-2m.club-internet.fr ([194.158.104.41])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 193F6x-0003VT-00
for <[EMAIL PROTECTED]>; Wed, 09 Apr 2003 05:55:31 -0700
Received: from meeloo.net (f12v-10-204.d1.club-internet.fr [213.44.181.204])
by relay-2m.club-internet.fr (Postfix) with ESMTP id D95F8168C
for <[EMAIL PROTECTED]>; Wed, 9 Apr 2003 14:54:56 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: Sebastien Metrot <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] nglInputDevice proposal
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Wed Apr 9 05:57:02 2003
X-Original-Date: Wed, 09 Apr 2003 14:54:53 +0200
Vincent Caron wrote:
> Sebastien Metrot wrote:
>
>> I'd add :
>> nglString GetButtonName(uint i);
>> nglString GetAxeName(uint i);
>
>
> How can we fill these ? I can't do better than 'axis %d' and 'button
> %d' for Linux, what is the state for other APIs ?
I think there are APIs for this both in Win32 and Mac. I'll check asap.
>
>> Any reason why some attributes are public?
>
>
> They are public but in a private class (this header is internal,
> namely in src/input/), this way we don't have to code the Get/Set
> accessors for every field. The NGL user does not know about
> nglInputDeviceInstance.
>
>
Hmmm... :-/
MeeLoo
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 198qUD-0000W9-00
for <[EMAIL PROTECTED]>; Thu, 24 Apr 2003 16:50:42 -0700
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id 97179B3CC
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 01:50:41 +0200 (CEST)
Received: from 192.168.1.3
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Fri, 25 Apr 2003 01:50:41 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: [NGL-devel] Possible new font for NGL
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 24 16:51:05 2003
X-Original-Date: Fri, 25 Apr 2003 01:50:41 +0200 (CEST)
Bitstream and the Gnome project released a whole font family (sans, serif and
mono
with slant/weight combinations) with a very cool license. They are very well
designed
and hinted truetype fonts. I now use these fonts with antialising on my whole
desktop,
and besides the lack of gamma correction, it's very slick and crisp all over the
place. Really impressive (at last!).
The mono face could replace our current one (also from Bitstream, a medium
quality
hinted Postscript font). Here is a comparison with some comments :
http://zerodeux.net/misc/ngl/fontcomp.html
Hard to make the choice, I like different features in both. I globally prefer
Vera
because it looks lighter without the serifs. Non-alphanumeric characters are
also much
nicer.
Comments ?
Received: from zerodeux.net ([62.212.104.175])
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 198rfJ-0007Nn-00
for <[EMAIL PROTECTED]>; Thu, 24 Apr 2003 18:06:13 -0700
Received: from zerodeux.net (localhost [127.0.0.1])
by zerodeux.net (Postfix) with SMTP id E8558B3CC
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 03:06:12 +0200 (CEST)
Received: from 192.168.1.3
(SquirrelMail authenticated user zerodeux)
by zerodeux.net with HTTP;
Fri, 25 Apr 2003 03:06:13 +0200 (CEST)
Message-ID: <[EMAIL PROTECTED]>
From: "Vincent Caron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
X-Mailer: SquirrelMail (version 1.2.10)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: [NGL-devel] NGL (very) short-term status
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 24 18:07:05 2003
X-Original-Date: Fri, 25 Apr 2003 03:06:13 +0200 (CEST)
A quick list of what's pending in my working repository :
* autoconf/automake support : fully implemented and tested for Linux, will be a
hell
of a commit technically speaking. Will break the Carbon build until someone
finds it
cool to debug M4 under MacOSX. Will break the NUI build until it also goes
autoconf/automake.
The was a tedious job (autoconf is _evil_), but maintenance has become a
thrill. Now
install/uninstall, source and doc packaging (gz/bz2/zip) and package testing
(package,extract,build,install,uninstall,check leftovers) is fully automated.
Configuration is also easier (and more standard), and dependencies are
automatically
detected and used (ie. libpng on/off, freetype on/off, ccache, etc). Running
'./configure' spits a lot of things and then :
Host family : unix
Build : debug
Compiler : ccache g++ (g++ (GCC) 3.2.3 20030415 (Debian prerelease))
Display : X11
Extensions : XF86VidMode
Text conv. : iconv
PNG support : yes
JPEG support : yes
FreeType support : yes
As for automake, this is hopefully simple and efficient. Makefiles have the same
number of lines than whith the home-grown build scheme. You get static+dynamic
libraries, wrapper for running examples against DLL, deep dependency tracking
(including automake files themselves), parallel build and a handful of nice
thingies
which all come virtually for free. Example for release mode :
-rwxr-xr-x 1 zerodeux zerodeux 20604 Apr 25 02:59
examples/gears/.libs/gears
-rwxr-xr-x 1 zerodeux zerodeux 465668 Apr 25 02:59
src/.libs/libngl.so.0.0.0
* input device : I've written a documentation on the internals, and a nice
interactive
demo is almost finished (~1h work). The question of axis & buttons naming is
pending,
waiting until we have more info (or an implementation) for other platforms than
Linux.
* fonts : the metrics demo needs to be finished, and
nglGlyphLayout::GetGlyphAt()
should be implemented and demonstrated (several hours, this is boring and
delicate).
At this point, the actual nglFont will be deprecated.
To keep some time for adaptation in NUI, I proposed to rename all classes with
their
final names in NGL, using 'nglFont1' for the to-be-depracated class. This way
NGL can
finalize its API immediatly and NUI implements the new font backend
progressively and
in parallel of the old one. Can be commited at any time, this is secretary work.
* streams : I'm about to merge input and output streams into their own single
bidirectionnal class. It should mean that removing the 'I' and 'O' in your code
should
be sufficient, since the new API will be the union of input & output streams.
This
move is mandatory for network support IMHO. This job will be mostly easy, needs
more
work on the memory stream classes which are currently not bidirectionnal-ready
at all.
* I've got other things about nglConsole, nglString and nglImage, but I don't
explicitely require them for the release (and I don't expect much API breakage
there).
Since I'd like to do some polishing (doc like INSTALL is outdated) and a test
release
before going public, there's enough work for the next weeks. What about setting
a
release date to help the motivation ? Since Thursday May 15 is the Matrix
Reloaded
release (USA & Cannes), that could be a match :).
Received: from meeloo.net ([62.4.18.112])
by sc8-sf-list1.sourceforge.net with esmtp
(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))
id 198wt1-0005Me-00
for <[EMAIL PROTECTED]>; Thu, 24 Apr 2003 23:40:44 -0700
Received: from [10.1.1.131] (helo=meeloo.net ident=HydraIRC)
by meeloo.net with esmtp (Exim 3.35 #1 (Debian))
id 198wsR-0002JC-00
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 08:40:07 +0200
Message-ID: <[EMAIL PROTECTED]>
From: Sebastien Metrot <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] Possible new font for NGL
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 24 23:42:12 2003
X-Original-Date: Fri, 25 Apr 2003 08:40:03 +0200
I agree: Vera is very nice. I vote for its inclusion in ngl :).
Nice comparison too :).
Meeloo
Vincent Caron wrote:
>Bitstream and the Gnome project released a whole font family (sans, serif and
>mono
>with slant/weight combinations) with a very cool license. They are very well
>designed
>and hinted truetype fonts. I now use these fonts with antialising on my whole
>desktop,
>and besides the lack of gamma correction, it's very slick and crisp all over
>the
>place. Really impressive (at last!).
>
>The mono face could replace our current one (also from Bitstream, a medium
>quality
>hinted Postscript font). Here is a comparison with some comments :
>
> http://zerodeux.net/misc/ngl/fontcomp.html
>
>Hard to make the choice, I like different features in both. I globally prefer
>Vera
>because it looks lighter without the serifs. Non-alphanumeric characters are
>also much
>nicer.
>
>Comments ?
>
>
>
>
Received: from meeloo.net ([62.4.18.112])
by sc8-sf-list1.sourceforge.net with esmtp
(Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))
id 198x3a-0001Vk-00
for <[EMAIL PROTECTED]>; Thu, 24 Apr 2003 23:51:39 -0700
Received: from [10.1.1.131] (helo=meeloo.net ident=HydraIRC)
by meeloo.net with esmtp (Exim 3.35 #1 (Debian))
id 198x31-0002MK-00
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 08:51:03 +0200
Message-ID: <[EMAIL PROTECTED]>
From: Sebastien Metrot <[EMAIL PROTECTED]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3)
Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] NGL (very) short-term status
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Thu Apr 24 23:53:03 2003
X-Original-Date: Fri, 25 Apr 2003 08:51:00 +0200
As May 16th is my 31 birthday let's say I'd love to get this as a
present :D.
Sorry for not being able to help much at the moment, my new job is quite
overwhelming (we are in release mode too).
I've been toying with changing some big stuff in NUI last week end: i'm
trying to get partial rendering working on opengl and software. It's
almost ok but still needs some work (i'll have to break down
nuiMainWindow as Vincent predicted for quite a while :).
I'll try to look into the current pending ngl issues for win32/OSX as
soon as I can (may be this week end...).
MeeLoo
Vincent Caron wrote:
>A quick list of what's pending in my working repository :
>
>
>* autoconf/automake support : fully implemented and tested for Linux, will be
>a hell
>of a commit technically speaking. Will break the Carbon build until someone
>finds it
>cool to debug M4 under MacOSX. Will break the NUI build until it also goes
>autoconf/automake.
>
>The was a tedious job (autoconf is _evil_), but maintenance has become a
>thrill. Now
>install/uninstall, source and doc packaging (gz/bz2/zip) and package testing
>(package,extract,build,install,uninstall,check leftovers) is fully automated.
>Configuration is also easier (and more standard), and dependencies are
>automatically
>detected and used (ie. libpng on/off, freetype on/off, ccache, etc). Running
>'./configure' spits a lot of things and then :
>
> Host family : unix
> Build : debug
> Compiler : ccache g++ (g++ (GCC) 3.2.3 20030415 (Debian prerelease))
> Display : X11
> Extensions : XF86VidMode
> Text conv. : iconv
> PNG support : yes
> JPEG support : yes
> FreeType support : yes
>
>As for automake, this is hopefully simple and efficient. Makefiles have the
>same
>number of lines than whith the home-grown build scheme. You get static+dynamic
>libraries, wrapper for running examples against DLL, deep dependency tracking
>(including automake files themselves), parallel build and a handful of nice
>thingies
>which all come virtually for free. Example for release mode :
>
>-rwxr-xr-x 1 zerodeux zerodeux 20604 Apr 25 02:59
>examples/gears/.libs/gears
>-rwxr-xr-x 1 zerodeux zerodeux 465668 Apr 25 02:59
>src/.libs/libngl.so.0.0.0
>
>
>* input device : I've written a documentation on the internals, and a nice
>interactive
>demo is almost finished (~1h work). The question of axis & buttons naming is
>pending,
>waiting until we have more info (or an implementation) for other platforms
>than Linux.
>
>
>* fonts : the metrics demo needs to be finished, and
>nglGlyphLayout::GetGlyphAt()
>should be implemented and demonstrated (several hours, this is boring and
>delicate).
>At this point, the actual nglFont will be deprecated.
>
>To keep some time for adaptation in NUI, I proposed to rename all classes with
>their
>final names in NGL, using 'nglFont1' for the to-be-depracated class. This way
>NGL can
>finalize its API immediatly and NUI implements the new font backend
>progressively and
>in parallel of the old one. Can be commited at any time, this is secretary
>work.
>
>
>* streams : I'm about to merge input and output streams into their own single
>bidirectionnal class. It should mean that removing the 'I' and 'O' in your
>code should
>be sufficient, since the new API will be the union of input & output streams.
>This
>move is mandatory for network support IMHO. This job will be mostly easy,
>needs more
>work on the memory stream classes which are currently not bidirectionnal-ready
>at all.
>
>
>* I've got other things about nglConsole, nglString and nglImage, but I don't
>explicitely require them for the release (and I don't expect much API breakage
>there).
>Since I'd like to do some polishing (doc like INSTALL is outdated) and a test
>release
>before going public, there's enough work for the next weeks. What about
>setting a
>release date to help the motivation ? Since Thursday May 15 is the Matrix
>Reloaded
>release (USA & Cannes), that could be a match :).
>
>
>
Received: from smtp-105-friday.nerim.net ([62.4.16.105] helo=kraid.nerim.net)
by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1
(Debian))
id 199040-0004Ap-00
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 03:04:16 -0700
Received: from vincent (mksp.net2.nerim.net [62.4.19.30])
by kraid.nerim.net (Postfix) with ESMTP id CB6D240F84
for <[EMAIL PROTECTED]>; Fri, 25 Apr 2003 12:04:11 +0200 (CEST)
From: Vincent Caron <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [NGL-devel] NGL (very) short-term status
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Fri, Apr 25, 2003
at 08:51:00 +0200
X-Mailer: Balsa 2.0.10
Lines: 6
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [EMAIL PROTECTED]
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Id: NGL developers discussion list <ngl-devel.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ngl-devel>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ngl-devel>
Date: Fri Apr 25 03:05:06 2003
X-Original-Date: Fri, 25 Apr 2003 12:04:12 +0200
On 2003.04.25 08:51, Sebastien Metrot wrote:
> As May 16th is my 31 birthday let's say I'd love to get this as a present
> :D.
Cool, 16th is also the Matrix release in french public theaters, 200% geeky
:).
