On 19 Oct 2000, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Lars" =3D=3D Lars Gullik Bj=F8nnes <[EMAIL PROTECTED]> writes:
> |=20
> | Lars> We don't want it in the .h file use a unsigned logn as parameter
> | Lars> to the lyx::mkdir
> |=20
> | I've
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> We don't want it in the .h file use a unsigned logn as parameter
| Lars> to the lyx::mkdir
|
| I've done it already. BTW, is there a readon why we still have in
| lyxlib.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I live under the suspicion that Norway does not exist at all
| as state of its own.
Covert state?
| And Russian submarines keep sinking close to the Norwegian
| shore... this is more than suspicious!
And we had a british Naval Vessel on ground some w
Allan Rae <[EMAIL PROTECTED]> writes:
| If you have any other concerns you are worried may bring retaliation
| measures send them to me privately and we can discuss a covert plan of
| action. Assuming of course that Lars doesn't have any friends within the
| CIA and its Carnivore crew.
Sorry, n
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> We don't want it in the .h file use a unsigned logn as parameter
Lars> to the lyx::mkdir
I've done it already. BTW, is there a readon why we still have in
lyxlib.h versions of functions taking char* as argument instead of
stri
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Allan> I can see why you might want to make entries in a struct static
| Allan> but surely the function signatures should match. At least
| Allan> switching to something like my suggestion you keep the function
| Allan> signatures matching irresp
Allan Rae <[EMAIL PROTECTED]> writes:
| On 18 Oct 2000, Jean-Marc Lasgouttes wrote:
|
| > > "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
| >
| > Juergen> A fast question: "Where is mode_t defined?" I'm not able to
| > Juergen> compile the last version as in some modules it does no
> Assuming of course that Lars doesn't have any friends within the
> CIA and its Carnivore crew.
I live under the suspicion that Norway does not exist at all
as state of its own.
Remember, their national anthem "Norwegian Wood" was written
by an _American_!
Well, perhaps not a _real_ American,
On 19 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
> Allan> Actually here's an even better question. Why does
> Allan> support/lyxlib.h contain:
> [...]
> Allan> I can see why you might want to make entries in a struct static
> Allan> but surely t
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> So it looks like is a safe bet so is there some
Allan> reason this hasn't been checked/fixed yet?
I used unsigned long int instead. We do not want to include header
files in lyxlib.h
Allan> Actually here's an even better question. W
On 18 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>
> Juergen> A fast question: "Where is mode_t defined?" I'm not able to
> Juergen> compile the last version as in some modules it does not have
> Juergen> mode_t defined as type!
>
> That
On 18-Oct-2000 Jean-Marc Lasgouttes wrote:
>
> That's a question that I briefly asked myself when looking at Angus
> patch. I think we should revert to some safe value (unsigned int?) in
> lyxlib.h, since we prefer not to have to include headers there (but
> only in respective implementations).
On Wed, 18 Oct 2000, Juergen Vigna wrote:
> > I said "claim" only in the context that making a formal (mathematical)
> > proof that your code does not contain bugs take too much time.
>
> #:O)
>
> A fast question: "Where is mode_t defined?" I'm not able to compile the
> last version as in some mod
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> A fast question: "Where is mode_t defined?" I'm not able to
Juergen> compile the last version as in some modules it does not have
Juergen> mode_t defined as type!
That's a question that I briefly asked myself when looking at A
>
> I said "claim" only in the context that making a formal (mathematical)
> proof that your code does not contain bugs take too much time.
>
#:O)
A fast question: "Where is mode_t defined?" I'm not able to compile the
last version as in some modules it does not have mode_t defined as type!
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 18-Oct-2000 Lars Gullik Bjønnes wrote:
| >
| > I _never_ said that (it is Asger and Jürgen that claims that their
| > code do not have bugs), my code ave bugs all the time.
|
| What means "claim" here?! There are NO bugs in our code!
I said "claim
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I have uploaded to ftp.lyx.org and ftp.devel.lyx.org now.
OK, I'll prepare the patch.
JMarc
On 18-Oct-2000 Lars Gullik Bjønnes wrote:
>
> I _never_ said that (it is Asger and Jürgen that claims that their
> code do not have bugs), my code ave bugs all the time.
What means "claim" here?! There are NO bugs in our code!
I will admit that there are sometimes, some "missing features", but
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Not warnings, INFO's.
|
| OK, OK, Lars, we all know your code is not buggy ;)
I _never_ said that (it is Asger and Jürgen that claims that their
code do not have bugs),
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Third time lucky?
Yes, it looks good.
I applied it.
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Not warnings, INFO's.
OK, OK, Lars, we all know your code is not buggy ;)
JMarc
Angus Leeming <[EMAIL PROTECTED]> writes:
| Third time lucky?
|
| The attached patch addresses all Jean-Marc's issues and results in a clean
| compile of support, save only for three warnings in DebugStream.C
Not warnings, INFO's.
Lgb
Third time lucky?
The attached patch addresses all Jean-Marc's issues and results in a clean
compile of support, save only for three warnings in DebugStream.C
Angus
patch_support2.bz2
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Wed, 18 Oct 2000, Jean-Marc Lasgouttes wrote:
| > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > Angus> I admit it: this makes more sense. (Although I hasten to point
| > Angus> out that I did not break anything!)
| >
| > Angus> W
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
|
| Angus> I admit it: this makes more sense. (Although I hasten to point
| Angus> out that I did not break anything!)
|
| Angus> Will you change this or shall I? A
|
| I'd prefer to l
On Wed, 18 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I admit it: this makes more sense. (Although I hasten to point
> Angus> out that I did not break anything!)
>
> Angus> Will you change this or shall I? A
>
> I'd prefer to let y
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I admit it: this makes more sense. (Although I hasten to point
Angus> out that I did not break anything!)
Angus> Will you change this or shall I? A
I'd prefer to let you do it :)
Other things:
* in StrPool: change the type of
> Why do you cast from 'unsigned int' in LRegex.C? It seems to me that
> the right change would be to return a pair of size_type (as MatchPair
> is declared) insetead of a pair of unsigned int (in
> LRegex::first_match and LRegex::exec at least)
I admit it: this makes more sense. (Although I hast
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> No cast at all. Makes sense (makes me sound like an expert.
Angus> Which I'm not!). Modified patch attached.
Why do you cast from 'unsigned int' in LRegex.C? It seems to me that
the right change would be to return a pair of size_t
On Wed, 18 Oct 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | Below are the remaining warning messages in support.
> | Note that count returns distance_type. Shall I cast this off to
> | unsigned int?
> iterator_traits<>::difference_type you mean.
No, distance_t
Angus Leeming <[EMAIL PROTECTED]> writes:
| Below are the remaining warning messages in support.
| Note that count returns distance_type. Shall I cast this off to
| unsigned int?
iterator_traits<>::difference_type you mean.
return an unsigned int or size_t.
size-t is probably best.
Lgb
> | Shall I
> | 1 do nothing;
> | 2 sputc(char(c));
> | 3 sputc(traits::to_char_type(c));
>
> Do nothing...
Ok. Nothing done! At least not here...
Attached is a small patch that cleans up most of support. Same old stuff.
I've been careful when making explicit casts and have used the correct ttyp
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars, here's one for you since I see that you wrote the code and it means
| nothing to me!
|
| Compiling support/DebugStream.C I get
|
| cxx: Info: DebugStream.C, line 94: #1136-D conversion to integral type of
| smaller size could lose dat
Lars, here's one for you since I see that you wrote the code and it means
nothing to me!
Compiling support/DebugStream.C I get
cxx: Info: DebugStream.C, line 94: #1136-D conversion to integral type of
smaller size could lose data
sb2->sputc(c);
34 matches
Mail list logo
