On Tue, May 13, 2008 at 10:55:50AM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > PS: As a bold but reasonably educated guess: We could get rid of 90% of
> > the code in support/* _and_ reduce compile and link times by a third (on
> > top of that what we gaine
"Bo Peng" <[EMAIL PROTECTED]> writes:
> and no response from Edwin and JMarc.
Yes, I intend to remain out of this discussion, which looks like it is
going to be tough (again!). That said, I planned to answer your
message ("nothing to declare") and then forgot. Sorry.
JMarc
José Matos <[EMAIL PROTECTED]> writes:
> On Friday 09 May 2008 10:35:00 Abdelrazak Younes wrote:
>> We (I think I can speak for everybody) certainly want you to be the
>> 1.6.x stable release manager. You made a pretty good job at managing 1.5.x.
>
> +1
me too!
Andre Poenitz <[EMAIL PROTECTED]> writes:
> PS: As a bold but reasonably educated guess: We could get rid of 90% of
> the code in support/* _and_ reduce compile and link times by a third (on
> top of that what we gained lately _and_ get a decent socket _and_ get
> a decent concurrency framework if
José Matos schrieb:
anyway its strange to have announcement of alternative win installer of
alpha1 without any tarball or offic installer being announced too.
Again I think that this was an honest mistake too. :-)
Yes the alpha1 release was a mistake since svn was tagged as alpha1 for a we
On Saturday 10 May 2008 19:14:42 Pavel Sanda wrote:
> > Alpha releases are not usually advertised in the users lists and people
> > in the devel certainly know how to compile from svn.
>
> i stand corrected then.
> anyway its strange to have announcement of alternative win installer of
> alpha1 w
José Matos wrote:
> Please Pavel,
> let us calm down. :-)
sorry if my mail sounded rude, i didn't intend that.
> Uwe has made an honest effort to follow the rules, and although we have not
> officially released an alpha version we have done it in the sense that we (I)
> have tagged th
On Saturday 10 May 2008 14:49:42 Pavel Sanda wrote:
>
> you are wrong. nothing was released - check annoucement list or news on web
> site. Jose only published tarball to test and since the tests failed,
> nothing was released - except your self-designated win alpha2 snapshot,
> which shouldn't hap
> On Friday 09 May 2008 00:57:35 Pavel Sanda wrote:
> > > we are short before the first beta
> >
> > first alpha in fact.
> > secondly Jose fall in love with distcheck, so wait for next few weeks :))
>
> If make distcheck was working none of the previous fiascoes would happen. :-(
if you have boo
> >> we are short before the first beta
> >
> > first alpha in fact.
>
> No alpha 2 is already release,
you are wrong. nothing was released - check annoucement list or news on web
site. Jose only published tarball to test and since the tests failed, nothing
was released - except your self-designat
On Fri, May 09, 2008 at 04:40:01PM +0200, Andre Poenitz wrote:
> On Thu, May 08, 2008 at 06:13:45PM -0400, rgheck wrote:
> > by making additional uses of the path information we're wrongly storing.
> > Right now, that information is used only to locate the file we need. On
> > your proposal, it w
On Fri, May 09, 2008 at 03:34:19PM +0300, Martin Vermeer wrote:
> Andre Poenitz <[EMAIL PROTECTED]> wrote:
>
> > PS: As a bold but reasonably educated guess: We could get rid of 90% of
> > the code in support/* _and_ reduce compile and link times by a third (on
> > top of that what we gained latel
On Thu, May 08, 2008 at 06:13:45PM -0400, rgheck wrote:
> by making additional uses of the path information we're wrongly storing.
> Right now, that information is used only to locate the file we need. On
> your proposal, it would also be used for something else, namely, update
> from external f
On Thu, May 08, 2008 at 04:58:16PM -0500, Bo Peng wrote:
> >> The inclusion of filepath in .lyx file has always been allowed, and
> >> will continue to be allowed. In another word, this is not a problem
> >> with embedding, but a general problem with using external files. It
> >> would be nice if e
On Thu, 08 May 2008 20:45:33 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:
> On Thu, May 08, 2008 at 01:08:21PM -0500, Bo Peng wrote:
> > > > 1. A libb64 library is copied to src/support/base64. (this is a
> > > > sourceforge project with a do-whatever-you-want license). Functions
> > > > are
Bo Peng wrote:
Dear all,
When I thought again about my design goal of the embedding feature
"creating a lyx format with embedded files that can be opened directly
by anyone on any OS, and produce identical outputs", I realized that
bundle/unbundle is not the only way to implement it. Considering
On Friday 09 May 2008 00:57:35 Pavel Sanda wrote:
> > we are short before the first beta
>
> first alpha in fact.
> secondly Jose fall in love with distcheck, so wait for next few weeks :))
If make distcheck was working none of the previous fiascoes would happen. :-(
> pavel
--
José Abílio
Abdelrazak Younes wrote:
We (I think I can speak for everybody) certainly want you to be the
1.6.x stable release manager. You made a pretty good job at managing 1.5.x.
+2
outstanding job i would say...
>> we are short before the first beta
>
> first alpha in fact.
No alpha 2 is already release, normally Jose would have releases alpha 3 this week without the
distcheck problem. In two weeks beta 1 should come out.
regards Uwe
On Friday 09 May 2008 10:35:00 Abdelrazak Younes wrote:
> We (I think I can speak for everybody) certainly want you to be the
> 1.6.x stable release manager. You made a pretty good job at managing 1.5.x.
+1
> Abdel.
--
José Abílio
Jürgen Spitzmüller wrote:
Andre Poenitz wrote:
The important part is that once the basic design is accepted, it is
accepted. Period. If you keep quiet, your opinion will be ignored
later. Also, I will respond only to sensible criticisms and
suggestions, not to personal insults.
I thin
Andre Poenitz wrote:
> > The important part is that once the basic design is accepted, it is
> > accepted. Period. If you keep quiet, your opinion will be ignored
> > later. Also, I will respond only to sensible criticisms and
> > suggestions, not to personal insults.
>
> I think I understand your
On Thu, May 8, 2008 at 4:56 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Thursday 08 May 2008 22:23:57 Bo Peng wrote:
>> This assertion, 'placing even more information in the lyx file than
>> before', is plain wrong. Embeding is not placing *more* information in
>> the lyx file. It places the *sa
> we are short before the first beta
first alpha in fact.
secondly Jose fall in love with distcheck, so wait for next few weeks :))
pavel
> If you are proposing a totally different approach, you need to show
> that why your approach is better than mine, and convince others to
> stop my attemp in the next few days, with maybe a plan to implement
> yours by yourself.
No, no, that's not how is goes! Your embeddeding code has been remo
> > if its problem to address in the anonymous way you have written before,
> > probably some warning dialog before saving could be one way how to
> > 'address' it.
>
> I do not know. But again, however you address it, this is not a
> problem with embedding.
technically you are right, that this
On Thursday 08 May 2008 23:06:31 rgheck wrote:
> Edwin's python script for the time being.
I did not know Edwin's python activities. :-)
I think that you referring to Enrico here. :-)
> rh
--
José Abílio
Bo Peng wrote:
Now with the full path we are placing even more information in the lyx file
than before.
This assertion, 'placing even more information in the lyx file than
before', is plain wrong. Embeding is not placing *more* information in
the lyx file. It places the *same* informatio
> Well, it's going to be some time, I'm afraid, until any more progess is
> made. I'm swamped busy until mid-June. But the great bulk of the code is
> already there. Just diff it against the last sync'd revision.
I will do that this weekend. If it is convenient to you, please send a
patch, and pos
Bo Peng wrote:
people ought to have a
look at that code, which is in my private branch. It's not finished, but it
does work, and it is very unintrusive, both in terms of its impact on the
rest of the code and in terms of its impact on the UI (which amounts to one
menu entry).
I can wait fo
>> The inclusion of filepath in .lyx file has always been allowed, and
>> will continue to be allowed. In another word, this is not a problem
>> with embedding, but a general problem with using external files. It
>> would be nice if embedding can help address this problem, but there is
>> nothing w
On Thursday 08 May 2008 22:23:57 Bo Peng wrote:
> This assertion, 'placing even more information in the lyx file than
> before', is plain wrong. Embeding is not placing *more* information in
> the lyx file. It places the *same* information in the .lyx file as
> before regarding the filepath issue.
On Thu, May 08, 2008 at 04:15:10PM -0500, Bo Peng wrote:
> [...]
> That is to say, I will give you guys a limited time frame within which
> you can express your opinions.
> 1. If you disagree with basic design, you can vote against it.
> 2. If you dislike certain part of the design, please object w
> > > safe', he was not able to provide any solid example that demonstrates
> > > any potential security issue with putting filepath + filename + file
> > > content in a .lyx file.
> >
> > very easy to provide. in linux you usually have files in your home
> > directory.
> > once you put your t
Richard,
I will try to be short.
> Indeed. <...>
This is not a problem with embedding at all. If you can address this
issue without changing how we use lyx, that is great. But this is not
at all my problem and should not be used to object this approach.
> But what's more important,< ...> But
Pavel Sanda wrote:
safe', he was not able to provide any solid example that demonstrates
any potential security issue with putting filepath + filename + file
content in a .lyx file.
very easy to provide. in linux you usually have files in your home directory.
once you put your the whole fi
> Now with the full path we are placing even more information in the lyx file
> than before.
This assertion, 'placing even more information in the lyx file than
before', is plain wrong. Embeding is not placing *more* information in
the lyx file. It places the *same* information in the .lyx file
On Thu, May 8, 2008 at 3:30 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > safe', he was not able to provide any solid example that demonstrates
> > any potential security issue with putting filepath + filename + file
> > content in a .lyx file.
>
> very easy to provide. in linux you usually hav
> I have explained before that this was the reason we have stopped the
> inclusion
> of the user name in the lyx file.
the same was the reason of CT-author-name flamewar shortly before 1.5.0 release.
and the same was the result :)
pavel
On Thursday 08 May 2008 21:30:06 Pavel Sanda wrote:
> very easy to provide. in linux you usually have files in your home
> directory. once you put your the whole filepath it contains your username.
> now this is 50% of success in case you want to assault some machine via
> some dictionary attack, b
> safe', he was not able to provide any solid example that demonstrates
> any potential security issue with putting filepath + filename + file
> content in a .lyx file.
very easy to provide. in linux you usually have files in your home directory.
once you put your the whole filepath it contains yo
Andre Poenitz wrote:
No commit is final. So let's see how it looks like.
sure
On Thu, May 08, 2008 at 09:08:52PM +0200, Edwin Leuven wrote:
> Andre Poenitz wrote:
>> Now, what about stopping personal insults if there's a chance that
>> they may be meant seriously?
>
> fyi:
>
> Bo Peng wrote:
> > No, I am known to be short of humor and I was not
> > tempting to show any.
>
>
Andre Poenitz wrote:
Now, what about stopping personal insults if there's a chance that
they may be meant seriously?
fyi:
Bo Peng wrote:
> No, I am known to be short of humor and I was not
> tempting to show any.
...
it may be me, but i find these type of ultimatums:
Bo Peng wrote:
> If yo
On Thu, May 08, 2008 at 08:48:52PM +0200, Edwin Leuven wrote:
> Bo Peng wrote:
>> On Thu, May 8, 2008 at 12:42 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
>>> Bo Peng wrote:
>>>
What would be your alternative?
>>> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html
>> If you ar
Bo Peng wrote:
On Thu, May 8, 2008 at 12:42 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
What would be your alternative?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html
If you are proposing a totally different approach, you need to show
that why your approa
On Thu, May 08, 2008 at 01:08:21PM -0500, Bo Peng wrote:
> > > 1. A libb64 library is copied to src/support/base64. (this is a
> > > sourceforge project with a do-whatever-you-want license). Functions
> > > are provided to encode/decode a file to/from base64 strings.
> >
> > QByteArray::fromBas
> > 1. A libb64 library is copied to src/support/base64. (this is a
> > sourceforge project with a do-whatever-you-want license). Functions
> > are provided to encode/decode a file to/from base64 strings.
>
> QByteArray::fromBase64(). It's even ok to use in support/*...
This is great. I did no
On Thu, May 8, 2008 at 12:42 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
>
> > What would be your alternative?
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html
If you are proposing a totally different approach, you need to show
that why your approach is better
On Thu, May 08, 2008 at 10:56:10AM -0500, Bo Peng wrote:
> Dear all,
>
> [...]
> Details (see the attached patch):
>
> 1. A libb64 library is copied to src/support/base64. (this is a
> sourceforge project with a do-whatever-you-want license). Functions
> are provided to encode/decode a file to/fr
Bo Peng wrote:
What would be your alternative?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html
> > 5. Files can be individually embedded.
>
> i don't like this very much. it leads to unnecessary clutter in the ui and
> the code imho
What would be your alternative? If you have a global 'embed' or 'do
not embed' option or mode,
1. The same action of insertion would need to different results
Bo Peng wrote:
5. Files can be individually embedded.
i don't like this very much. it leads to unnecessary clutter in the ui
and the code imho
no response from Edwin and JMarc
i tried your patch but it crashed on me
If you have persuasive arguments against this approach, please speak
ou
Dear all,
When I thought again about my design goal of the embedding feature
"creating a lyx format with embedded files that can be opened directly
by anyone on any OS, and produce identical outputs", I realized that
bundle/unbundle is not the only way to implement it. Considering the
troubles wit
54 matches
Mail list logo
