Menu
▾
▴
arpix-devel — The Arpix project development mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(21) |
Feb
(63) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Simo S. <sim...@xs...> - 2001-11-08 14:23:30
|
Hi, folks, it had been a looong time since last I've heard of you. anyone still alive? --=20 Simo Sorce - sim...@xs... Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 |
|
From: Giovanni C. <val...@li...> - 2001-03-25 10:52:48
|
On 24 Mar 2001 17:07:46 +0100, Hongli Lai wrote: > My PC came back from repairs, and they formatted my harddrive. > My CD-ROM player doesn't work so I can't install Linux. > It will soon be taken away for yet another repair. :-( > > BTW, has any progress been made in the development while I was gone? > > _______________________________________________ > Arpix-devel mailing list > Arp...@li... > http://lists.sourceforge.net/lists/listinfo/arpix-devel Nice to hear you again. I have news, both bad and good. The bad one is that I couldn't work on {tar|tgz}lib, because I was really busy with my exams. The good one is that right now I'm studying Software Engineering and C++. IMHO, these things can help us a lot. Giovanni -- Bart: Conosco un sito dove le scimmie fanno le cosacce. Homer: Hu-hu! Scimmie! |
|
From: Hongli L. <ho...@te...> - 2001-03-24 16:07:45
|
My PC came back from repairs, and they formatted my harddrive. My CD-ROM player doesn't work so I can't install Linux. It will soon be taken away for yet another repair. :-( BTW, has any progress been made in the development while I was gone? |
|
From: Hongli L. <ho...@te...> - 2001-02-21 22:14:54
|
I'll be going to America at Saturday (vacation) for a whole week. Funnily enough, I don't think I will enjoy it. Second, I'm having some problems with my IDE controllers. At Friday, it will be taken away for repairs. I don't know when my PC will come back. But it will be more than a week. In the meantime, keep submitting patches to the mailing list. I will commit them when I'm back. |
|
From: Hongli L. <ho...@te...> - 2001-02-16 13:58:07
|
On Fri, 16 Feb 2001 10:39:28 Simo Sorce wrote:
> This problem may arise anyway also if we put the code in libgarp.
> What you need is a consistent locking system for system wide variables
> and a per thread
> variabile set for the variabile the are related only to a thread.
I think you misunderstood me.
In this case, using a locking system would "lock too much".
The current method is to extract a file to the working directory:
f = fopen("file.zip", "w");
fwrite (f, some_data);
fclose (f);
What I want is to change ziplib/tarlib's API to something like this:
void zlextract(gchar *extract_to, gchar *file_to_extract)
{
gchar *fn = g_strdup_printf ("%s/%s", extract_to, file_to_extract);
f = fopen (fn, "w");
fwrite (f, some_data);
fclose (f);
}
|
|
From: Simo S. <sim...@ti...> - 2001-02-16 09:40:37
|
Hongli Lai wrote: > > On Thu, 15 Feb 2001 09:21:14 Giovanni Corriga wrote: > > Maybe we can keep this workaround as a rule. I think that handling > > extraction directory is a garp-[zip|tar|tgz] issue, not > > [zip|tar|tgz]lib's. But if you think otherwise, I think I can add a > > tl_extractfiletodir() function to tarlib. > > The current workaround is by setting the working directory while > extracting. > But this kind of workaround is not threadsafe. > I planned pthread support in some later version of GnomeZip, > so I want everything to be more or less threadsafe. > Imagine extraction a file to one directory, while using another > window (of the same app) to extract some other file to some > other directory. > Imagine GarpArchive 1 sets the working directory to /foo, > then the pthread lib gives the control to GarpArchive 2. > GarpArchive 2's chdir() code has already been executed beforem\, > so it extracts. But because the working directory has been > altered by GarpArchive 1, it would extract to the wrong dir. > See the problem? > This problem may arise anyway also if we put the code in libgarp. What you need is a consistent locking system for system wide variables and a per thread variabile set for the variabile the are related only to a thread. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2001-02-15 15:06:56
|
On Thu, 15 Feb 2001 09:21:14 Giovanni Corriga wrote: > Maybe we can keep this workaround as a rule. I think that handling > extraction directory is a garp-[zip|tar|tgz] issue, not > [zip|tar|tgz]lib's. But if you think otherwise, I think I can add a > tl_extractfiletodir() function to tarlib. The current workaround is by setting the working directory while extracting. But this kind of workaround is not threadsafe. I planned pthread support in some later version of GnomeZip, so I want everything to be more or less threadsafe. Imagine extraction a file to one directory, while using another window (of the same app) to extract some other file to some other directory. Imagine GarpArchive 1 sets the working directory to /foo, then the pthread lib gives the control to GarpArchive 2. GarpArchive 2's chdir() code has already been executed beforem\, so it extracts. But because the working directory has been altered by GarpArchive 1, it would extract to the wrong dir. See the problem? |
|
From: Simo S. <sim...@ti...> - 2001-02-15 14:58:36
|
Giovanni, do not send html formatted mails please. Use text only! -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Giovanni C. <val...@li...> - 2001-02-15 08:19:40
|
On 14 Feb 2001 19:36:31 +0100, Simo Sorce wrote:
> Hongli Lai wrote:
> >
> > Ziplib only extracts to the work directory.
> > I've added a workaround in GarpZip using g_get_current_dir() and chdir()
> > Simo, could you fix this bug?
Maybe we can keep this workaround as a rule. I think that handling
extraction directory is a garp-[zip|tar|tgz] issue, not
[zip|tar|tgz]lib's. But if you think otherwise, I think I can add a
tl_extractfiletodir() function to tarlib.
> >
> > BTW, you could also take a look at tarlib's extraction code on how to
> > create block devices and FIFOs.
>
> These things are on my todo list in first position, unfortunately I'm
> really busy these days as I'm releasing a product form my employee.
>
Il'be busy too. I don't think I'll have mush spare time before the end
of February.
Giovanni
--
Bart: Conosco un sito dove le scimmie fanno le cosacce.
Homer: Hu-hu! Scimmie!
|
|
From: Simo S. <sim...@ti...> - 2001-02-14 18:37:52
|
Hongli Lai wrote: > > Ziplib only extracts to the work directory. > I've added a workaround in GarpZip using g_get_current_dir() and chdir() > Simo, could you fix this bug? > > BTW, you could also take a look at tarlib's extraction code on how to > create block devices and FIFOs. These things are on my todo list in first position, unfortunately I'm really busy these days as I'm releasing a product form my employee. I hope to be able to fix these things asap, but I may be busy till the first week of march. Sorry. Simo. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2001-02-14 17:10:45
|
I'm planning to release LibGarp 0.2.1, since I fixed (read: found a workaround) for some serious bugs. Could you guys please test GnomeZip to see if LibGarp is truly bugfree (or at least nearly) this time? Don't mind any bugs in the View dialog, because I'm not going to release a new GnomeZip. |
|
From: Hongli L. <ho...@te...> - 2001-02-14 17:03:00
|
Same story in tarlib. It only extracts to the working directory. |
|
From: Hongli L. <ho...@te...> - 2001-02-14 17:00:39
|
Ziplib only extracts to the work directory. I've added a workaround in GarpZip using g_get_current_dir() and chdir() Simo, could you fix this bug? BTW, you could also take a look at tarlib's extraction code on how to create block devices and FIFOs. |
|
From: Simo S. <sim...@ti...> - 2001-02-10 11:10:37
|
Giovanni Corriga wrote: > > On 10 Feb 2001 02:23:14 +0100, Simo Sorce wrote: > > Giovanni Corriga wrote: > > > > > > On 09 Feb 2001 15:42:05 +0100, Hongli Lai wrote: > > > > On Fri, 09 Feb 2001 15:11:53 Giovanni Corriga wrote: > > > > > I'm quite not satisfied by the way the info about the archive content is > > > > > manipulated (a GList holding a fileinfo struct). I was thinking to > > > > > replace it with a custom list (a FiList) derived from the standard > > > > > GList. > > > > > I have written some code for you to review. Please note that I haven't > > > > > even tried to compile it. > > > > > > > > > > What do you think? > > > > > > > > I don't see why it is neccesary. > > > > > > > > > > Just good OOP. It is not really necessary - just an itch that needs to > > > be scratched. ;-) > > > > > > > I've not seen any difference or advancement against a standard GList, > > what's the point? > > You may add a function to misc if you want other manipulation function > > above the standard provided one. > > Can you explain exactly where your implementation has it's strenght and > > why it so better than standard Glist (Isn't Filist a simple typedef? > > I've not seen a different structure) > > > > As I said, it is not necessary. We can go on using the fileinfo struct. > I simply thought that > > filist_get_size(fi); > > was easier to understand than > > (((fileinfo *)(list->data))->size); > > It was just a proposal, but since it seems you don't like it, I will > drop it. > It's not that we do not like it, is that it is not necessary to change the name of a structure to add functions. Simply do this: #define g_list_get_data_size(list) (((fileinfo *)(list->data))->size); the GList is preserved and a more clear way to get the size is addressed the same way. ;) Feel free to add this kind of #define if they result in cleaner and more readable code. Bye, Simo. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Giovanni C. <val...@li...> - 2001-02-10 09:52:08
|
On 10 Feb 2001 02:23:14 +0100, Simo Sorce wrote:
> Giovanni Corriga wrote:
> >
> > On 09 Feb 2001 15:42:05 +0100, Hongli Lai wrote:
> > > On Fri, 09 Feb 2001 15:11:53 Giovanni Corriga wrote:
> > > > I'm quite not satisfied by the way the info about the archive content is
> > > > manipulated (a GList holding a fileinfo struct). I was thinking to
> > > > replace it with a custom list (a FiList) derived from the standard
> > > > GList.
> > > > I have written some code for you to review. Please note that I haven't
> > > > even tried to compile it.
> > > >
> > > > What do you think?
> > >
> > > I don't see why it is neccesary.
> > >
> >
> > Just good OOP. It is not really necessary - just an itch that needs to
> > be scratched. ;-)
> >
>
> I've not seen any difference or advancement against a standard GList,
> what's the point?
> You may add a function to misc if you want other manipulation function
> above the standard provided one.
> Can you explain exactly where your implementation has it's strenght and
> why it so better than standard Glist (Isn't Filist a simple typedef?
> I've not seen a different structure)
>
As I said, it is not necessary. We can go on using the fileinfo struct.
I simply thought that
filist_get_size(fi);
was easier to understand than
(((fileinfo *)(list->data))->size);
It was just a proposal, but since it seems you don't like it, I will
drop it.
--
Max, could you please feed my cat?
Heisenberg says he can't. Bye,
Schroedinger
|
|
From: Simo S. <sim...@ti...> - 2001-02-10 01:24:20
|
Giovanni Corriga wrote: > > On 09 Feb 2001 15:42:05 +0100, Hongli Lai wrote: > > On Fri, 09 Feb 2001 15:11:53 Giovanni Corriga wrote: > > > I'm quite not satisfied by the way the info about the archive content is > > > manipulated (a GList holding a fileinfo struct). I was thinking to > > > replace it with a custom list (a FiList) derived from the standard > > > GList. > > > I have written some code for you to review. Please note that I haven't > > > even tried to compile it. > > > > > > What do you think? > > > > I don't see why it is neccesary. > > > > Just good OOP. It is not really necessary - just an itch that needs to > be scratched. ;-) > I've not seen any difference or advancement against a standard GList, what's the point? You may add a function to misc if you want other manipulation function above the standard provided one. Can you explain exactly where your implementation has it's strenght and why it so better than standard Glist (Isn't Filist a simple typedef? I've not seen a different structure) -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Giovanni C. <val...@li...> - 2001-02-09 18:23:31
|
On 09 Feb 2001 15:42:05 +0100, Hongli Lai wrote:
> On Fri, 09 Feb 2001 15:11:53 Giovanni Corriga wrote:
> > I'm quite not satisfied by the way the info about the archive content is
> > manipulated (a GList holding a fileinfo struct). I was thinking to
> > replace it with a custom list (a FiList) derived from the standard
> > GList.
> > I have written some code for you to review. Please note that I haven't
> > even tried to compile it.
> >
> > What do you think?
>
> I don't see why it is neccesary.
>
Just good OOP. It is not really necessary - just an itch that needs to
be scratched. ;-)
--
Max, could you please feed my cat?
Heisenberg says he can't. Bye,
Schroedinger
|
|
From: Hongli L. <ho...@te...> - 2001-02-09 14:41:49
|
On Fri, 09 Feb 2001 15:11:53 Giovanni Corriga wrote: > I'm quite not satisfied by the way the info about the archive content is > manipulated (a GList holding a fileinfo struct). I was thinking to > replace it with a custom list (a FiList) derived from the standard > GList. > I have written some code for you to review. Please note that I haven't > even tried to compile it. > > What do you think? I don't see why it is neccesary. |
|
From: Giovanni C. <val...@li...> - 2001-02-09 14:10:45
|
I'm quite not satisfied by the way the info about the archive content is
manipulated (a GList holding a fileinfo struct). I was thinking to
replace it with a custom list (a FiList) derived from the standard
GList.
I have written some code for you to review. Please note that I haven't
even tried to compile it.
What do you think?
--
Max, could you please feed my cat?
Heisenberg says he can't. Bye,
Schroedinger
|
|
From: Simo S. <sim...@ti...> - 2001-02-09 09:00:47
|
Giovanni Corriga wrote: > > On 06 Feb 2001 19:22:14 +0100, Simo Sorce wrote: > > > > using zlib and bzlib is a good way, and I'm thinking if is it the case > > to unify tarlib and ziplib to share as much code as possibile. > > > > Do you mean e.g using the same interface style and the same data structs > (mainly fileinfo)? That'a a way! I think doing so we may have an unique consistent interface to ease it's use. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2001-02-08 20:11:49
|
On Thu, 08 Feb 2001 20:14:13 Giovanni Corriga wrote: > I'm sending you the patch for fifo support in tgzlib. I want to keep the > same pace in developing both tgzlib and tarlib. Comitted. Thanks. |
|
From: Hongli L. <ho...@te...> - 2001-02-08 20:08:53
|
On Thu, 08 Feb 2001 20:14:16 Giovanni Corriga wrote: > Do you mean e.g using the same interface style and the same data structs > (mainly fileinfo)? Not exactly, but that would be a beginning. What I mean is trying to do as much as possible with just one codebase. So when you, for example, add a new field in struct fileinfo, you don't have to copy the implementation code from tarlib to tgzlib. Support tar and tgz with as little code as possible. |
|
From: Giovanni C. <val...@li...> - 2001-02-08 19:13:11
|
On 06 Feb 2001 19:22:14 +0100, Simo Sorce wrote:
>
> using zlib and bzlib is a good way, and I'm thinking if is it the case
> to unify tarlib and ziplib to share as much code as possibile.
>
Do you mean e.g using the same interface style and the same data structs
(mainly fileinfo)?
--
Max, could you please feed my cat?
Heisenberg says he can't. Bye,
Schroedinger
|
|
From: Giovanni C. <val...@li...> - 2001-02-08 19:13:08
|
I'm sending you the patch for fifo support in tgzlib. I want to keep the
same pace in developing both tgzlib and tarlib.
Giovanni
--
Max, could you please feed my cat?
Heisenberg says he can't. Bye,
Schroedinger
|
|
From: Hongli L. <ho...@te...> - 2001-02-08 14:41:23
|
On Thu, 08 Feb 2001 13:46:25 Giovanni Corriga wrote: > I can't open uncompressed tar files with gnomezip. It reports that this > file format is not supported. Fixed. |