It's to run Pike faster directly from the build tree. You don't get them by the normal build targets, but once you've dumped them they'll get updated by those targets. Run the target undump_modules to keep them from coming back.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 00:30: Subject: Image.SSL?

---

If I remove all ".pmod.o" files, then the problem disappears. But as soon as I run "make", the files get redumped and the problem reapprears. What's with this sudden dumping of modules in the build tree? That never used to happen before...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

The dumping before the doc target is intentional since it uses the build tree pike, and several times too (or at least it did). This system has worked and still works well for me; it automatically manages most cases where they can become invalid.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 01:43: Subject: Image.SSL?

---

I seems that running 'make documentation' triggers the dumping, a rather unfortunate side effect. Besides, what's the use of running Pike faster when it doesn't work proplerly?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

The first module that failed to dump correctly with `make dump_modules' is Array:

#### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Failed to index module 'Array' with 'diff' (module doesn't exist?) Compilation failed. /pike/home/marcus/Pike/7.3/build/master.pike:382: master()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod" ,dumpmodule.pike()->Handler(),0,0) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:197: dumpmodule.pike()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Ar ray.pmod",dumpmodule.pike()->Handler()) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:245: dumpmodule.pike()->dumpit("/pike/home/marcus/Pike/7.3/lib/modules/Array.pm od","lib/modules/Array.pmod") /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:225: dumpmodule.pike()->dumpit("/pike/home/marcus/Pike/7.3/lib/modules","lib/mo dules") /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:386: dumpmodule.pike()->main(7,({"/pike/home/marcus/Pike/7.3/lib/modules"}))

Line 671 does indeed contain a (rather unneccesary) recursive reference, but it dumps fine with `make install', so it's still `make dump_modules' that is at fault.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 12:28: Subject: Image.SSL?

---

Well, it doesn't work for me. I vote that it is disabled until it is fixed so that it works for everybody.

For example:

pelix:~/Pike/7.3/build% ls -l lib/modules/Tools.pmod/X509.pmod.o -rw-rw-r-- 1 marcus marcus 168 Nov 26 12:26 lib/modules/Tools.pmod/X509.pmod.o pelix:~/Pike/7.3/build% ls -l /pike/sw/pike/7.3.62/lib/modules/Tools.pmod/X509.pmod.o -rw-rw-r-- 1 root other 20133 Nov 26 00:35 /pike/sw/pike/7.3.62/lib/modules/Tools.pmod/X509.pmod.o pelix:~/Pike/7.3/build%

The first is the broken dump generated by make dump_modules. The second is the correct dump generated by make install.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Just add a sort to the get_dir in install_dir() and the dump order will be totally deterministic. Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 15:46: Subject: Image.SSL?

---

Seems to me that the fault is the incomplete handling of cyclic references in the compiler. dumpmodule.pike is used in both cases, so problems of this kind could occur during installation too if the phase of the moon produces an unfortunate module order then. A kludge is perhaps to add an adhoc ordering in dumpmodule.pike when dumping of certain modules is requested.

/ Martin Stjernholm, Roxen IS

Speaking of SSL, my recent HTTP(s) problems seems to have something to do with this:

| int len=(int)headers["content-length"]; | werror("len=%O z(len)=%O\n",len,zero_type(len));

gives the dump "len=2653 z(len)=2122".

Is this really correct?

(Snip from Protocols.HTTP.Query.)

If B needs A to be loaded first

dump A B dump C

will work. If a user has the private module A2 it will make the following executions

dump A A2 dump B C

which will break, since A isn't loaded in the Pike that dumps B. Or am I wrong?

/ Martin Nilsson (Hossnij)

Previous text:

2002-11-26 16:30: Subject: Image.SSL?

---

Uh, the dump order, and thus the dump behaviour, will be deterministic within a specific Pike _release_, which means that if it dumps ok in pikefarm, it will dump ok at the end users machine as well.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Yes, and that's not the only thing I find peculiar. It's also peculiar that a dependency error(?) causes an invalid dump to be written at all, as seems to be the case in 9377727. Looks like there's a misguided catch or similar somewhere.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:39: Subject: Image.SSL?

---

I'm not talking about "private modules", I'm talking about the distribution.

Btw, it seems a little odd that dumping order should be relevant to whether a module that _refers itself_ can be dumped or not. Anybody else who finds this peculiar?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Then the gap in the error propagation lies in dumpmodule.pike. It should not dump any modules at all if one module has failed to compile earlier (unless more accurate tracking of the dependencies is implemented).

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:15: Subject: Image.SSL?

---

No, there are no dumps written from modules which give errors, and there is no error message written when dumping the X509 module. The reason that the X509 module becomes empty is probably that the dump of the ASN1 module failed (there is an #if constant(ASN1.something) around all the code in X509).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Actually both bugs appears to be relevant, but for different reasons. I'll try to make dumpmodules.pike behave better.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:33: Subject: Image.SSL?

---

Yes, but it seems more relevant to fix the bug that causes the dumping of ASN1.pmod to fail in the first place. :-)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Not really.

/ Henrik Grubbström (Lysator)

Previous text:

2002-11-26 22:17: Subject: Image.SSL?

---

The #error directives in the database modules cause trouble, but I think that way of reporting the lack of support is wrong anyway. Would there be any problems if they were removed so that the problem is "reported" just like most other optional modules (i.e. by providing a module with no identifiers)?

/ Martin Stjernholm, Roxen IS

It is wrong to have the documentation target do dump_modules, since it triggers a stateful change in the build tree.

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 17:37: Subject: Image.SSL?

---

Ok, they are removed and dumpmodules.pike has been changed to abort if compilation fails. Thus I don't think it can do any harm to have dump_modules on the documentation target anymore.

/ Martin Stjernholm, Roxen IS

I don't see why it's wrong to do a stateful change then.

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

Because everyone else has to know that to make the doc extraction go faster. I see it only as an optimization of that process, nothing more. Anyway, as Nilsson says there are not so many pikes spawned anymore, so it's not such a vital optimization as it was when I wrote it.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-27 17:53: Subject: Image.SSL?

---

It is wrong to have the documentation target do dump_modules, since it triggers a stateful change in the build tree.

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

I don't see why it's wrong to do a stateful change then.

Because it wasn't asked for. There is a separate target to ask for it, so use it.

Because everyone else has to know that to make the doc extraction go faster.

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 18:42: Subject: Image.SSL?

---

I don't see why it's wrong to do a stateful change then.

...

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

Because everyone else has to know that to make the doc extraction go faster. I see it only as an optimization of that process, nothing more. Anyway, as Nilsson says there are not so many pikes spawned anymore, so it's not such a vital optimization as it was when I wrote it.

/ Martin Stjernholm, Roxen IS

It depends on what you think is "asked for". There are numerous other targets that have more far reaching effects than one might expect at first, e.g. both the install and documentation targets can build a pike.

It's hardly surprsing that an install-target builds the thing it's supposed to install. How else would it be able to install it?

But you can go ahead and remove the dependency if it makes you feel better. It's no longer an important optimization.

I already did. Several hours ago.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 19:11: Subject: Image.SSL?

---

It depends on what you think is "asked for". There are numerous other targets that have more far reaching effects than one might expect at first, e.g. both the install and documentation targets can build a pike.

...

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

That's not bothersome if the process doesn't bug out, and now those bugs have been located and fixed. It's just a cache like the kept object files; the only difference is that it's optional.

But you can go ahead and remove the dependency if it makes you feel better. It's no longer an important optimization.

/ Martin Stjernholm, Roxen IS

It depends on what you think is "asked for". There are numerous other targets that have more far reaching effects than one might expect at first, e.g. both the install and documentation targets can build a pike.

It's hardly surprsing that an install-target builds the thing it's supposed to install. How else would it be able to install it?

But you can go ahead and remove the dependency if it makes you feel better. It's no longer an important optimization.

I already did. Several hours ago.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 19:11: Subject: Image.SSL?

---

It depends on what you think is "asked for". There are numerous other targets that have more far reaching effects than one might expect at first, e.g. both the install and documentation targets can build a pike.

...

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

That's not bothersome if the process doesn't bug out, and now those bugs have been located and fixed. It's just a cache like the kept object files; the only difference is that it's optional.

But you can go ahead and remove the dependency if it makes you feel better. It's no longer an important optimization.

/ Martin Stjernholm, Roxen IS

It depends on what you think is "asked for". There are numerous other targets that have more far reaching effects than one might expect at first, e.g. both the install and documentation targets can build a pike.

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

That's not bothersome if the process doesn't bug out, and now those bugs have been located and fixed. It's just a cache like the kept object files; the only difference is that it's optional.

But you can go ahead and remove the dependency if it makes you feel better. It's no longer an important optimization.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-27 18:46: Subject: Image.SSL?

---

...

I don't see why it's wrong to do a stateful change then.

Because it wasn't asked for. There is a separate target to ask for it, so use it.

...

Because everyone else has to know that to make the doc extraction go faster.

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

I don't see why it's wrong to do a stateful change then.

Because it wasn't asked for. There is a separate target to ask for it, so use it.

Because everyone else has to know that to make the doc extraction go faster.

Better than them having to know that typing `make documentation' will change the future build process of their pike, which is really counter-intuitive.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 18:42: Subject: Image.SSL?

---

I don't see why it's wrong to do a stateful change then.

...

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

Because everyone else has to know that to make the doc extraction go faster. I see it only as an optimization of that process, nothing more. Anyway, as Nilsson says there are not so many pikes spawned anymore, so it's not such a vital optimization as it was when I wrote it.

/ Martin Stjernholm, Roxen IS

I don't see why it's wrong to do a stateful change then.

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

Because everyone else has to know that to make the doc extraction go faster. I see it only as an optimization of that process, nothing more. Anyway, as Nilsson says there are not so many pikes spawned anymore, so it's not such a vital optimization as it was when I wrote it.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-27 17:53: Subject: Image.SSL?

---

It is wrong to have the documentation target do dump_modules, since it triggers a stateful change in the build tree.

If you want `make documentation' go faster, why not just do `make dump_modules' manually first? You only have to do it once anyway.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Ok, they are removed and dumpmodules.pike has been changed to abort if compilation fails. Thus I don't think it can do any harm to have dump_modules on the documentation target anymore.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 22:32: Subject: Image.SSL?

---

Not really.

/ Henrik Grubbström (Lysator)

The #error directives in the database modules cause trouble, but I think that way of reporting the lack of support is wrong anyway. Would there be any problems if they were removed so that the problem is "reported" just like most other optional modules (i.e. by providing a module with no identifiers)?

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:58: Subject: Image.SSL?

---

Actually both bugs appears to be relevant, but for different reasons. I'll try to make dumpmodules.pike behave better.

/ Martin Stjernholm, Roxen IS

Yes, but it seems more relevant to fix the bug that causes the dumping of ASN1.pmod to fail in the first place. :-)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:26: Subject: Image.SSL?

---

Then the gap in the error propagation lies in dumpmodule.pike. It should not dump any modules at all if one module has failed to compile earlier (unless more accurate tracking of the dependencies is implemented).

/ Martin Stjernholm, Roxen IS

Then the gap in the error propagation lies in dumpmodule.pike. It should not dump any modules at all if one module has failed to compile earlier (unless more accurate tracking of the dependencies is implemented).

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:15: Subject: Image.SSL?

---

No, there are no dumps written from modules which give errors, and there is no error message written when dumping the X509 module. The reason that the X509 module becomes empty is probably that the dump of the ASN1 module failed (there is an #if constant(ASN1.something) around all the code in X509).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

No, there are no dumps written from modules which give errors, and there is no error message written when dumping the X509 module. The reason that the X509 module becomes empty is probably that the dump of the ASN1 module failed (there is an #if constant(ASN1.something) around all the code in X509).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:10: Subject: Image.SSL?

---

Yes, and that's not the only thing I find peculiar. It's also peculiar that a dependency error(?) causes an invalid dump to be written at all, as seems to be the case in 9377727. Looks like there's a misguided catch or similar somewhere.

/ Martin Stjernholm, Roxen IS

Yes, and that's not the only thing I find peculiar. It's also peculiar that a dependency error(?) causes an invalid dump to be written at all, as seems to be the case in 9377727. Looks like there's a misguided catch or similar somewhere.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:39: Subject: Image.SSL?

---

I'm not talking about "private modules", I'm talking about the distribution.

Btw, it seems a little odd that dumping order should be relevant to whether a module that _refers itself_ can be dumped or not. Anybody else who finds this peculiar?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

I'm not talking about "private modules", I'm talking about the distribution.

Btw, it seems a little odd that dumping order should be relevant to whether a module that _refers itself_ can be dumped or not. Anybody else who finds this peculiar?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 16:37: Subject: Image.SSL?

---

If B needs A to be loaded first

dump A B dump C

will work. If a user has the private module A2 it will make the following executions

dump A A2 dump B C

which will break, since A isn't loaded in the Pike that dumps B. Or am I wrong?

/ Martin Nilsson (räfsfiskal)

If B needs A to be loaded first

dump A B dump C

will work. If a user has the private module A2 it will make the following executions

dump A A2 dump B C

which will break, since A isn't loaded in the Pike that dumps B. Or am I wrong?

/ Martin Nilsson (räfsfiskal)

Previous text:

2002-11-26 16:30: Subject: Image.SSL?

---

Uh, the dump order, and thus the dump behaviour, will be deterministic within a specific Pike _release_, which means that if it dumps ok in pikefarm, it will dump ok at the end users machine as well.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Uh, the dump order, and thus the dump behaviour, will be deterministic within a specific Pike _release_, which means that if it dumps ok in pikefarm, it will dump ok at the end users machine as well.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 16:26: Subject: Image.SSL?

---

The dump order will be, but not the dump behavior since not all file names are sent to the dump program at once. It will be deterministic within a specific Pike tree though, which is better than today.

/ Martin Nilsson (räfsfiskal)

That won't affect the dump order for the dump_modules target since it doesn't use install.pike. A sort of the result from get_dir inside dumpmodule.pike is also necessary. Unfortunately the normal sort() can't be used reliably since it's locale dependent.

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:21: Subject: Image.SSL?

---

Just add a sort to the get_dir in install_dir() and the dump order will be totally deterministic. Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

I wouldn't mind, anyway. Meanwhile a trick is to use indices(mkmultiset(foo)).

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:47: Subject: Image.SSL?

---

Could anyone plase fix the sort function...

/ Martin Nilsson (Hossnij)

No, and the reason it isn't is that some of us want it not to be in the future. Locale.sort (which isn't implemented yet) is supposed to have the behaviour of the current sort function, IIRC.

/ Johan Sundström (ärkehertig av Lysators rootgrupp)

Previous text:

2002-11-26 17:42: Subject: Image.SSL?

---

Is it specified somewhere to be locale dependant?

/ Mirar

But not as evil when publicly declared as such (both in the docs and the name).

/ Johan Sundström (ärkehertig av Lysators rootgrupp)

Previous text:

2002-11-26 17:45: Subject: Image.SSL?

---

External locale dependencies are evil.

/ Peter Bortas

External locale dependencies are evil.

/ Peter Bortas (Kein Paket!)

Previous text:

2002-11-26 17:45: Subject: Image.SSL?

---

No, and the reason it isn't is that some of us want it not to be in the future. Locale.sort (which isn't implemented yet) is supposed to have the behaviour of the current sort function, IIRC.

/ Johan Sundström (Achtung Liebe!)

I wouldn't mind, anyway. Meanwhile a trick is to use indices(mkmultiset(foo)).

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:47: Subject: Image.SSL?

---

Could anyone plase fix the sort function...

/ Martin Nilsson (räfsfiskal)

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 16:46: Subject: Image.SSL?

---

That won't affect the dump order for the dump_modules target since it doesn't use install.pike. A sort of the result from get_dir inside dumpmodule.pike is also necessary. Unfortunately the normal sort() can't be used reliably since it's locale dependent.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

/ Martin Stjernholm, Roxen IS

No. Whereever the svalue for len comes from, it isn't correctly initialized. The source appears to be the cast, but I can't duplicate this error there.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:56: Subject: zero_type-p?

---

Speaking of SSL, my recent HTTP(s) problems seems to have something to do with this:

| int len=(int)headers["content-length"]; | werror("len=%O z(len)=%O\n",len,zero_type(len));

gives the dump "len=2653 z(len)=2122".

Is this really correct?

(Snip from Protocols.HTTP.Query.)

/ Mirar

The function is data() in Query.pike. I haven't been able to reproduce the error either. (I checked in a workaround for now.)

/ Mirar

Previous text:

2002-11-26 18:09: Subject: zero_type-p?

---

No. Whereever the svalue for len comes from, it isn't correctly initialized. The source appears to be the cast, but I can't duplicate this error there.

/ Martin Stjernholm, Roxen IS

It's silly to remove the dump_modules target because of this; it's enough to remove its use from the documentation target.

/.../ I haven's seen any problems with the dumping that make install does).

What has been seen and not accounts for nothing in this case since the there are bugs on a lower level which apparently are worked around in totally ad-hoc ways without any knowledge about exactly where and why it breaks. The only way to make such a kludge reliable is to make it deterministic in every possible way.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:48: Subject: Image.SSL?

---

...

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

It's silly to remove the dump_modules target because of this; it's enough to remove its use from the documentation target.

/.../ I haven's seen any problems with the dumping that make install does).

What has been seen and not accounts for nothing in this case since the there are bugs on a lower level which apparently are worked around in totally ad-hoc ways without any knowledge about exactly where and why it breaks. The only way to make such a kludge reliable is to make it deterministic in every possible way.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:48: Subject: Image.SSL?

---

...

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

It's silly to remove the dump_modules target because of this; it's enough to remove its use from the documentation target.

/.../ I haven's seen any problems with the dumping that make install does).

What has been seen and not accounts for nothing in this case since the there are bugs on a lower level which apparently are worked around in totally ad-hoc ways without any knowledge about exactly where and why it breaks. The only way to make such a kludge reliable is to make it deterministic in every possible way.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:48: Subject: Image.SSL?

---

...

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 16:46: Subject: Image.SSL?

---

That won't affect the dump order for the dump_modules target since it doesn't use install.pike. A sort of the result from get_dir inside dumpmodule.pike is also necessary. Unfortunately the normal sort() can't be used reliably since it's locale dependent.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

/ Martin Stjernholm, Roxen IS

That won't affect the dump order for the dump_modules target since it doesn't use install.pike.

No, but that's ok since we can simply remove the dump_modules target.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

That was what the sort in install.pike was supposed to fix (if there indeed _is_ anything to fix there, I haven's seen any problems with the dumping that make install does).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 16:46: Subject: Image.SSL?

---

That won't affect the dump order for the dump_modules target since it doesn't use install.pike. A sort of the result from get_dir inside dumpmodule.pike is also necessary. Unfortunately the normal sort() can't be used reliably since it's locale dependent.

...

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

/ Martin Stjernholm, Roxen IS

That won't affect the dump order for the dump_modules target since it doesn't use install.pike. A sort of the result from get_dir inside dumpmodule.pike is also necessary. Unfortunately the normal sort() can't be used reliably since it's locale dependent.

Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

Currently this applies to dumping during installation too.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 16:21: Subject: Image.SSL?

---

Just add a sort to the get_dir in install_dir() and the dump order will be totally deterministic. Anyway, dumping by make documentation should be disabled unless that dumping also can be made to work deterministically.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Yes, the dump order is not the whole truth; what's relevant is really the order in which the compiler makes recursive compilations. It e.g. matters which modules are read from dumps, and which modules that already are compiled when a certain module is resolved.

Do you have a similar minimized case where Array.pmod fails? That'd be more interesting.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:09: Subject: Image.SSL?

---

Actually, I'm getting rather sceptical to the claim that the dump order is relevant. Behold:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike ../src/dumpmodule.pike --log-file --report-failed --target-dir=/tmp ../lib/modules/Colors.pmod ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

Colors and Array are the two very first modules dumped by `make dump_modules'. So the order is exactly the same, yet Array dumps successfully in this case.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Ok, it all seems to boil down to how you specify the path to the module(s):

fails:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Failed to index module 'Array' with 'diff' (module doesn't exist?) Compilation failed. /pike/home/marcus/Pike/7.3/build/master.pike:382: master()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod" ,dumpmodule.pike()->Handler(),0,0) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:197: dumpmodule.pike()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Ar ray.pmod",dumpmodule.pike()->Handler()) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:245: dumpmodule.pike()->dumpit("/pike/home/marcus/Pike/7.3/lib/modules/Array.pm od","/tmp/Array.pmod") /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:386: dumpmodule.pike()->main(4,({"/pike/home/marcus/Pike/7.3/lib/modules/Array. pmod"})) Dumping failed for /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod

succeeds:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:17: Subject: Image.SSL?

---

In both cases I ran undump_modules before, so there were no dumped modules beforehand to load.

I'm working on it...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

I did a trace of the two cases (use a wide window...):

Working case:

[...] - master.pike: 566: 3462ac->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler(),progra.. - master.pike: 373: 3462ac->master_read_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 260: 3461d0->Fd() - -: 0: 3461a8->create() - master.pike: 263: 3461a8->open("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod","r") - master.pike: 262: 3461a8->read() - master.pike: 377: 3462ac->get_predefines() - master.pike: 382: 3462ac->get_default_module() - master.pike:1403: 3462ac->resolv("__default") - master.pike: 382: 3462ac->get_default_module() - master.pike:1403: 3462ac->resolv("__default") - master.pike: 382: 3462ac->resolv("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1492: 3462ac->resolv_base("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handl.. - master.pike:1417: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/build/lib/modules/__builtin",dumpmodule.pike()->Handler()) - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/lib/modules/__builtin",dumpmodule.pike()->Handler()) - master.pike: 382: 3462ac->resolv("Array","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1492: 3462ac->resolv_base("Array","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1417: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/build/lib/modules/Array",dumpmodule.pike()->Handler()) [...]

Non-working case:

[...] - master.pike: 566: 3476ec->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler(),progra.. - master.pike: 373: 3476ec->master_read_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 260: 347610->Fd() - -: 0: 3475e8->create() - master.pike: 263: 3475e8->open("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod","r") - master.pike: 262: 3475e8->read() - master.pike: 377: 3476ec->get_predefines() - master.pike: 382: 3476ec->get_default_module() - master.pike:1403: 3476ec->resolv("__default") - master.pike: 382: 3476ec->get_default_module() - master.pike:1403: 3476ec->resolv("__default") - master.pike: 382: 3476ec->resolv("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3476ec->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 382: 347688->compile_error("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",671,"Recursive module dependency i.. - dumpmodule.pike: 176: 347714->logmsg_long("%s:%d:%s\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",671,"Recursive module d.. - dumpmodule.pike: 157: 347714->logstart(0) - dumpmodule.pike: 140: 2da8bc->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - module.pmod:1418: 2da8bc->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - -: 0: 2daab0->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod")

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:31: Subject: Image.SSL?

---

Probably the crucial bit is whether the filename of the module to dump is already present in master()->programs due to dumpmodule.pike using that module.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

The entire traces are in ~/marcus/Pike/7.3/build/funk.txt and ~/marcus/Pike/7.3/build/ofunk.txt, if you think they will enable you to draw more useful conclusion. I could also recompile with more debug if you like, or add some strategic trace printouts. (I already tried looking at master()->programs, but it looks the same in both cases (except that in the nonworking case, the entry for Array.pmod becomes 0 and not a programs, since it fails to compile it)).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 18:23: Subject: Image.SSL?

---

I fail to draw any useful conclusions from that.

Anyway, the cyclic check is basically broken but it's hard to do away with it. An ugly kludge that probably would solve most real world problems would be to delay it five steps or so.

/ Martin Stjernholm, Roxen IS

Hm, I think I understand the problem now. It's the "resolve_cache". dumpmodule.pike creates a new master to get rid of cached stuff in master()->programs etc so that the classes used by dumpmodule itself doesn't interfere with the modules to dump. However, "resolve_cache" is hidden as a static variable in program.c, so it won't be cleared by replacing the master. In fact, there doesn't seem to be a way of clearing it at all. This seems rather terrible. Shouldn't the resolve cache be a variable in the master or something?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 18:23: Subject: Image.SSL?

---

I fail to draw any useful conclusions from that.

Anyway, the cyclic check is basically broken but it's hard to do away with it. An ugly kludge that probably would solve most real world problems would be to delay it five steps or so.

/ Martin Stjernholm, Roxen IS

Ok, this time I think I have it, actually. :-)

I added trace outputs to the BEGIN/END_CYCLIC calls in resolve_identifier(). The working dump:

BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod])

The nonworking dump:

BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

So the difference is that in the working case, two levels of recursion are allowed due to the resolved program and the compile_string:ed program having differemt paths, while in the nonworking case only one level of recursion is allowed, and this is (apparently) not enough. The problem only occurs when the source dir for dumping is in the module path (which it isn't in the `make install' case, since dumping is done from the installed directory, while the module path still points to the build tree).

What bugs me is that you claim that you can dump Array.pmod with only one level of recursion. Would you mind adding the same trace outputs to your pike? (You'll have to revert Array.pmod to rev 1.77 to get around Nilssons malevolent removal of the circular dependency.)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 12:30: Subject: Image.SSL?

---

Hm, or maybe not. It seems to be 0 before compilation starts in both cases. Back to the drawing board...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

In 9376067, you said that `make dump_modules' works for you.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 15:10: Subject: Image.SSL?

---

Did I claim that? (For a while I actually believed that such a reference would be handled internally by the compiler, but a reference by name to the whole class being compiled is of course not internal. I don't think I said that anywhere, though.)

/ Martin Stjernholm, Roxen IS

Ok. Good. Then we don't have to worry about the phase of the moon anymore. :-)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 18:26: Subject: Image.SSL?

---

Ok. I claimed it works, not exactly why it works. ;) The reason is that dumpmodule.pike got to Program.pmod first in my case, which trigged compilation of Array.pmod via resolv and not directly. If I try to dump Array.pmod explicitly like in 9380373 I get the same error.

/ Martin Stjernholm, Roxen IS

Ok. I claimed it works, not exactly why it works. ;) The reason is that dumpmodule.pike got to Program.pmod first in my case, which trigged compilation of Array.pmod via resolv and not directly. If I try to dump Array.pmod explicitly like in 9380373 I get the same error.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-27 17:09: Subject: Image.SSL?

---

In 9376067, you said that `make dump_modules' works for you.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Hm, another thing that's a little strange is what happens if I just load the undumped module:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike -e 'Array;' BEGIN_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) *** END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(Array, 327118 [-]) END_CYCLIC(Array, 327118 [-]) pelix:~/Pike/7.3/build%

For some reason, the recursive resolutions of __builtin and Array that happens at *** when dumping are not made here. How come?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 12:51: Subject: Image.SSL?

---

Ok, this time I think I have it, actually. :-)

I added trace outputs to the BEGIN/END_CYCLIC calls in resolve_identifier(). The working dump:

BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod])

The nonworking dump:

BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

So the difference is that in the working case, two levels of recursion are allowed due to the resolved program and the compile_string:ed program having differemt paths, while in the nonworking case only one level of recursion is allowed, and this is (apparently) not enough. The problem only occurs when the source dir for dumping is in the module path (which it isn't in the `make install' case, since dumping is done from the installed directory, while the module path still points to the build tree).

What bugs me is that you claim that you can dump Array.pmod with only one level of recursion. Would you mind adding the same trace outputs to your pike? (You'll have to revert Array.pmod to rev 1.77 to get around Nilssons malevolent removal of the circular dependency.)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

The symbol "Array" is set to 0 in the masters resolv_cache (not the internal one) somehow when resolv() (as opposed to compile_file()) is used to intially trigger the compilation of the module.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 17:43: Subject: Image.SSL?

---

Perhaps it's the internal resolve_cache that kicks in? But the question in that case is when the symbol is added there, and why it's different.

/ Martin Stjernholm, Roxen IS

Aha. Turning on RESOLV_DEBUG gave this insight:

BEGIN_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") => found 0 END_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

The resolv of "Array" short-circuits to a 0 in this case. This does not happen when dumping. In order for dumping of a module to work when the source file is in the module path, the masters resolve_cache must first be populated with an entry for the module name, so that the resolve() call can short-circuit. Adding

mkmodulename(0, file);

to the beginning of the dumpit function is enough to make this happen, although there might be a more obvious way to do it... :-)

This fix makes `make dump_modules' work decidedly better (X509 now has content again), so unless someone can think of a more beautiful fix RSN, I'm going to commit it.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 17:16: Subject: Image.SSL?

---

Hm, another thing that's a little strange is what happens if I just load the undumped module:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike -e 'Array;' BEGIN_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

---

END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(Array, 327118 [-]) END_CYCLIC(Array, 327118 [-]) pelix:~/Pike/7.3/build%

For some reason, the recursive resolutions of __builtin and Array that happens at *** when dumping are not made here. How come?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Your kludge seems very adhoc.

Yes. That's why I asked for a better one. Nobody submitted one though, so it will have to do for now.

A better fix would be to delay the cyclic check one step further, so that the resolver can return the placeholder object.

Be my guest.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-28 03:16: Subject: Image.SSL?

---

The returned zero is clearly bogus; it should return a placeholder object. The problem is that code in the master does things like

if (objects[prog]) ...

which doesn't cope with objects with tricky `!. Fixed in many places.

Your kludge seems very adhoc. A better fix would be to delay the cyclic check one step further, so that the resolver can return the placeholder object.

/ Martin Stjernholm, Roxen IS

Your kludge seems very adhoc.

Yes. That's why I asked for a better one. Nobody submitted one though, so it will have to do for now.

A better fix would be to delay the cyclic check one step further, so that the resolver can return the placeholder object.

Be my guest.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-28 03:16: Subject: Image.SSL?

---

The returned zero is clearly bogus; it should return a placeholder object. The problem is that code in the master does things like

if (objects[prog]) ...

which doesn't cope with objects with tricky `!. Fixed in many places.

Your kludge seems very adhoc. A better fix would be to delay the cyclic check one step further, so that the resolver can return the placeholder object.

/ Martin Stjernholm, Roxen IS

Aha. Turning on RESOLV_DEBUG gave this insight:

BEGIN_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") Resolv("Array", "/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") => found 0 END_CYCLIC(Array, 322eb8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

The resolv of "Array" short-circuits to a 0 in this case. This does not happen when dumping. In order for dumping of a module to work when the source file is in the module path, the masters resolve_cache must first be populated with an entry for the module name, so that the resolve() call can short-circuit. Adding

mkmodulename(0, file);

to the beginning of the dumpit function is enough to make this happen, although there might be a more obvious way to do it... :-)

This fix makes `make dump_modules' work decidedly better (X509 now has content again), so unless someone can think of a more beautiful fix RSN, I'm going to commit it.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 17:16: Subject: Image.SSL?

---

Hm, another thing that's a little strange is what happens if I just load the undumped module:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike -e 'Array;' BEGIN_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

---

END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 2e75b8 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 327118 [-]) BEGIN_CYCLIC(Array, 327118 [-]) END_CYCLIC(Array, 327118 [-]) pelix:~/Pike/7.3/build%

For some reason, the recursive resolutions of __builtin and Array that happens at *** when dumping are not made here. How come?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Did I claim that? (For a while I actually believed that such a reference would be handled internally by the compiler, but a reference by name to the whole class being compiled is of course not internal. I don't think I said that anywhere, though.)

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-27 12:51: Subject: Image.SSL?

---

Ok, this time I think I have it, actually. :-)

I added trace outputs to the BEGIN/END_CYCLIC calls in resolve_identifier(). The working dump:

BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod])

The nonworking dump:

BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

So the difference is that in the working case, two levels of recursion are allowed due to the resolved program and the compile_string:ed program having differemt paths, while in the nonworking case only one level of recursion is allowed, and this is (apparently) not enough. The problem only occurs when the source dir for dumping is in the module path (which it isn't in the `make install' case, since dumping is done from the installed directory, while the module path still points to the build tree).

What bugs me is that you claim that you can dump Array.pmod with only one level of recursion. Would you mind adding the same trace outputs to your pike? (You'll have to revert Array.pmod to rev 1.77 to get around Nilssons malevolent removal of the circular dependency.)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Ok, this time I think I have it, actually. :-)

I added trace outputs to the BEGIN/END_CYCLIC calls in resolve_identifier(). The working dump:

BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 349f78 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [../lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [../lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [../lib/modules/Array.pmod])

The nonworking dump:

BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(__builtin, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) BEGIN_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod]) END_CYCLIC(Array, 323080 [/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod])

So the difference is that in the working case, two levels of recursion are allowed due to the resolved program and the compile_string:ed program having differemt paths, while in the nonworking case only one level of recursion is allowed, and this is (apparently) not enough. The problem only occurs when the source dir for dumping is in the module path (which it isn't in the `make install' case, since dumping is done from the installed directory, while the module path still points to the build tree).

What bugs me is that you claim that you can dump Array.pmod with only one level of recursion. Would you mind adding the same trace outputs to your pike? (You'll have to revert Array.pmod to rev 1.77 to get around Nilssons malevolent removal of the circular dependency.)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 12:30: Subject: Image.SSL?

---

Hm, or maybe not. It seems to be 0 before compilation starts in both cases. Back to the drawing board...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Hm, or maybe not. It seems to be 0 before compilation starts in both cases. Back to the drawing board...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-27 12:23: Subject: Image.SSL?

---

Hm, I think I understand the problem now. It's the "resolve_cache". dumpmodule.pike creates a new master to get rid of cached stuff in master()->programs etc so that the classes used by dumpmodule itself doesn't interfere with the modules to dump. However, "resolve_cache" is hidden as a static variable in program.c, so it won't be cleared by replacing the master. In fact, there doesn't seem to be a way of clearing it at all. This seems rather terrible. Shouldn't the resolve cache be a variable in the master or something?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Hm, I think I understand the problem now. It's the "resolve_cache". dumpmodule.pike creates a new master to get rid of cached stuff in master()->programs etc so that the classes used by dumpmodule itself doesn't interfere with the modules to dump. However, "resolve_cache" is hidden as a static variable in program.c, so it won't be cleared by replacing the master. In fact, there doesn't seem to be a way of clearing it at all. This seems rather terrible. Shouldn't the resolve cache be a variable in the master or something?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 18:23: Subject: Image.SSL?

---

I fail to draw any useful conclusions from that.

Anyway, the cyclic check is basically broken but it's hard to do away with it. An ugly kludge that probably would solve most real world problems would be to delay it five steps or so.

/ Martin Stjernholm, Roxen IS

Hm, I think I understand the problem now. It's the "resolve_cache". dumpmodule.pike creates a new master to get rid of cached stuff in master()->programs etc so that the classes used by dumpmodule itself doesn't interfere with the modules to dump. However, "resolve_cache" is hidden as a static variable in program.c, so it won't be cleared by replacing the master. In fact, there doesn't seem to be a way of clearing it at all. This seems rather terrible. Shouldn't the resolve cache be a variable in the master or something?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 18:23: Subject: Image.SSL?

---

I fail to draw any useful conclusions from that.

Anyway, the cyclic check is basically broken but it's hard to do away with it. An ugly kludge that probably would solve most real world problems would be to delay it five steps or so.

/ Martin Stjernholm, Roxen IS

I did a trace of the two cases (use a wide window...):

Working case:

[...] - master.pike: 566: 3462ac->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler(),progra.. - master.pike: 373: 3462ac->master_read_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 260: 3461d0->Fd() - -: 0: 3461a8->create() - master.pike: 263: 3461a8->open("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod","r") - master.pike: 262: 3461a8->read() - master.pike: 377: 3462ac->get_predefines() - master.pike: 382: 3462ac->get_default_module() - master.pike:1403: 3462ac->resolv("__default") - master.pike: 382: 3462ac->get_default_module() - master.pike:1403: 3462ac->resolv("__default") - master.pike: 382: 3462ac->resolv("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1492: 3462ac->resolv_base("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handl.. - master.pike:1417: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/build/lib/modules/__builtin",dumpmodule.pike()->Handler()) - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/lib/modules/__builtin",dumpmodule.pike()->Handler()) - master.pike: 382: 3462ac->resolv("Array","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1492: 3462ac->resolv_base("Array","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1417: 3462ac->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike:1422: 3462ac->findmodule("/pike/home/marcus/Pike/7.3/build/lib/modules/Array",dumpmodule.pike()->Handler()) [...]

Non-working case:

[...] - master.pike: 566: 3476ec->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler(),progra.. - master.pike: 373: 3476ec->master_read_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 260: 347610->Fd() - -: 0: 3475e8->create() - master.pike: 263: 3475e8->open("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod","r") - master.pike: 262: 3475e8->read() - master.pike: 377: 3476ec->get_predefines() - master.pike: 382: 3476ec->get_default_module() - master.pike:1403: 3476ec->resolv("__default") - master.pike: 382: 3476ec->get_default_module() - master.pike:1403: 3476ec->resolv("__default") - master.pike: 382: 3476ec->resolv("__builtin","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",dumpmodule.pike()->Handler()) - master.pike:1478: 3476ec->dirname("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - master.pike: 382: 347688->compile_error("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",671,"Recursive module dependency i.. - dumpmodule.pike: 176: 347714->logmsg_long("%s:%d:%s\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod",671,"Recursive module d.. - dumpmodule.pike: 157: 347714->logstart(0) - dumpmodule.pike: 140: 2da8bc->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - module.pmod:1418: 2da8bc->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod") - -: 0: 2daab0->write("#### %s:\n","/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod")

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:31: Subject: Image.SSL?

---

Probably the crucial bit is whether the filename of the module to dump is already present in master()->programs due to dumpmodule.pike using that module.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Probably the crucial bit is whether the filename of the module to dump is already present in master()->programs due to dumpmodule.pike using that module.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:28: Subject: Image.SSL?

---

Ok, it all seems to boil down to how you specify the path to the module(s):

fails:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Failed to index module 'Array' with 'diff' (module doesn't exist?) Compilation failed. /pike/home/marcus/Pike/7.3/build/master.pike:382: master()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod" ,dumpmodule.pike()->Handler(),0,0) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:197: dumpmodule.pike()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Ar ray.pmod",dumpmodule.pike()->Handler()) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:245: dumpmodule.pike()->dumpit("/pike/home/marcus/Pike/7.3/lib/modules/Array.pm od","/tmp/Array.pmod") /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:386: dumpmodule.pike()->main(4,({"/pike/home/marcus/Pike/7.3/lib/modules/Array. pmod"})) Dumping failed for /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod

succeeds:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Ok, it all seems to boil down to how you specify the path to the module(s):

fails:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod #### /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod: /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Recursive module dependency in Array. /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod:671:Failed to index module 'Array' with 'diff' (module doesn't exist?) Compilation failed. /pike/home/marcus/Pike/7.3/build/master.pike:382: master()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Array.pmod" ,dumpmodule.pike()->Handler(),0,0) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:197: dumpmodule.pike()->compile_file("/pike/home/marcus/Pike/7.3/lib/modules/Ar ray.pmod",dumpmodule.pike()->Handler()) /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:245: dumpmodule.pike()->dumpit("/pike/home/marcus/Pike/7.3/lib/modules/Array.pm od","/tmp/Array.pmod") /pike/home/marcus/Pike/7.3/src/dumpmodule.pike:386: dumpmodule.pike()->main(4,({"/pike/home/marcus/Pike/7.3/lib/modules/Array. pmod"})) Dumping failed for /pike/home/marcus/Pike/7.3/lib/modules/Array.pmod

succeeds:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike /pike/home/marcus/Pike/7.3/src/dumpmodule.pike --report-failed --target-dir=/tmp ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:17: Subject: Image.SSL?

---

In both cases I ran undump_modules before, so there were no dumped modules beforehand to load.

I'm working on it...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

In both cases I ran undump_modules before, so there were no dumped modules beforehand to load.

I'm working on it...

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 17:14: Subject: Image.SSL?

---

Yes, the dump order is not the whole truth; what's relevant is really the order in which the compiler makes recursive compilations. It e.g. matters which modules are read from dumps, and which modules that already are compiled when a certain module is resolved.

Do you have a similar minimized case where Array.pmod fails? That'd be more interesting.

/ Martin Stjernholm, Roxen IS

Yes, the dump order is not the whole truth; what's relevant is really the order in which the compiler makes recursive compilations. It e.g. matters which modules are read from dumps, and which modules that already are compiled when a certain module is resolved.

Do you have a similar minimized case where Array.pmod fails? That'd be more interesting.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-11-26 17:09: Subject: Image.SSL?

---

Actually, I'm getting rather sceptical to the claim that the dump order is relevant. Behold:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike ../src/dumpmodule.pike --log-file --report-failed --target-dir=/tmp ../lib/modules/Colors.pmod ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

Colors and Array are the two very first modules dumped by `make dump_modules'. So the order is exactly the same, yet Array dumps successfully in this case.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Actually, I'm getting rather sceptical to the claim that the dump order is relevant. Behold:

pelix:~/Pike/7.3/build% /pike/home/marcus/Pike/7.3/build/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/pike/home/marcus/Pike/7.3/build/master.pike ../src/dumpmodule.pike --log-file --report-failed --target-dir=/tmp ../lib/modules/Colors.pmod ../lib/modules/Array.pmod pelix:~/Pike/7.3/build%

Colors and Array are the two very first modules dumped by `make dump_modules'. So the order is exactly the same, yet Array dumps successfully in this case.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2002-11-26 15:46: Subject: Image.SSL?

---

Seems to me that the fault is the incomplete handling of cyclic references in the compiler. dumpmodule.pike is used in both cases, so problems of this kind could occur during installation too if the phase of the moon produces an unfortunate module order then. A kludge is perhaps to add an adhoc ordering in dumpmodule.pike when dumping of certain modules is requested.

/ Martin Stjernholm, Roxen IS