|Pliant talk forum
Feature request: Rounded corner and others
|Message posted by michel on 2002/11/11 11:29:10
|On windows package it seems that components for that dll exists but are not compiled.
|Message posted by maybe Hubert Tonneau on 2002/11/11 11:35:21
|I don't understand what you mean. Could you elaborate ?
|Message posted by maybe pom on 2002/11/11 12:44:47
|The source files in /pliant/win32/jpeg-6b seems to be those of libjpeg.dll,
which should be placed in /binary. The only problem is that they are not compiled
in the .zip distribution. We have used various jpeg.dll present on the system
(renamed for the circumstance), in vain.
So, could you add the compile libjpeg.dll to the windows distribution.
|Message posted by maybe Hubert Tonneau on 2002/11/11 13:04:42
|Oops: I had forgotten to upgrade my packaging script so I have the libjpeg.dll
on my system, but it was not included in the .zip tarballs I publish on pliant.cx
I've uploaded a new
tarball with libjpeg.dll included.
|Message posted by maybe Hubert Tonneau on 2002/11/11 13:25:53
|Just in case:
the Pliant 'make-win32-i386-gcc' script I use to provide the Win32 executables
uses a cross GCC compiler to compile from Linux.
Should you want to compile yourself rather than use precompiled binaries, for
security reasons (doing so is rather questionable under Win32 since the all system
is binary only, anyway), then I've included 'i386-pc-cygwin.tgz' tarball
containing a ready to use GCC cross compiler (believe me, building a proper
cross compiling environment is a nightmare) that you can untar in /usr/local/
on your Linux system in order to be abble to run locally the 'make-win32-i386-gcc'
script (also the binaries in this tarball could also be questionable; it's a
nearly endless question if you want to be sure).
the DLLs I build for Win32 are not relocatable: they are mendatory to load at
the fixed address specified in 'make-win32-i386-gcc' script, so it might be
necessary to adjust the values if some Win32 users get the DLLs to fail to load
because of more heavilly loaded address space on huge servers.
Having DLLs mendatory to load at a fixed address is a good feature for the Pliant
DLLs since should the address change, then the precompiled dumps would not work
anymore. For the zlib and libjpeg DLLs, it's rather a bad feature, but it's because
I was too lazy to change my working cross compiling method.
The problem with compiling zlib and libjpeg is mainly that various Win32 compilers
tend to use different calling convension as opposed to Unix one which all use
the poor from efficiency point of view but very portable one, and in the zlib
and libjpeg source, the 'WINAPI' calling convension is properly specified in
the DLL functions prototype, but missing in the callback functions you provide
to the library, so basically none of these DLLs provided as binary on various other
projects site is usable with a different compiler.
|Message posted by hubert.tonneau on 2002/11/11 13:31:12
|If you look at 'make-win32-i386-gcc' script, you will see that just before
starting to compile the zlib and libjpeg DLLs, I do
compiler_options="-b i386-pc-cygwin -O2 -m486 -mrtd"
in order to force GCC to use WINAPI calling convension everywhere.
|Message posted by michel on 2002/11/11 16:28:26
|Round corner problem is solved, both with prerelease 3 when adding libjpg.dll
and relese 78 but if, with prerelease3 docs are OK, with release78 its impossible toload pages
with the "sample" instruction. I got this type of message
There is a bug in the dynamic page /pliantdocs/babel/universal/pliant/protocol/http/base.html (/pliantdocs/babel/fr/pliant/protocol/http/base.html).
Failed to compile sample (Str rc Str rc (List Str) rc)
compile /pliantdocs/babel/fr/pliant/protocol/http/base.page 25 1
compile /pliantdocs/babel/fr/pliant/protocol/http/base.page 5 1
compile /pliantdocs/babel/fr/pliant/protocol/http/base.page 2 1
parse /pliantdocs/babel/fr/pliant/protocol/http/base.page 412 65533
execute dynamic page /pliantdocs/babel/universal/virtual_tree.html
service HTTP request
|Message posted by michel on 2002/11/11 16:29:35
|Evidently it is 78a
|Message posted by maybe Hubert Tonneau on 2002/11/11 17:01:27
|Looks like a Patrice issue, also I may be abble to track those problems also
as soon as you have uploaded pliantdocs to the logical server I'll create for
|Message posted by maybe Marcus on 2002/11/25 15:29:10
|I just found out that the 'sample' instruction does not work under release 78.
Have you had problems with it Michel?
|Message posted by hubert.tonneau on 2002/11/25 15:59:35
|What URL ?
|Message posted by maybe Marcus on 2002/11/25 17:45:39
|Message posted by michel on 2002/11/26 10:17:21
|yes I had but I have no more this problem
|Message posted by michel on 2002/11/26 10:20:03
What is your OS ?, if windows see below to add the right patch (perhaps also for Linux)
|Message posted by maybe Marcus on 2002/11/26 11:32:47
So you have release 78 installed? Or one of the prereleases?
|Message posted by maybe Marcus on 2002/11/26 11:41:17
|Actually, the PDI documentation available on pliant.cx is now hosted in one of
Hubert's machines. Hence, supposedly running an up to date Pliant release.
|Message posted by hubert.tonneau on 2002/11/26 14:07:42
|I've uploaded http://pliant.cx/archive/pliant-79pre1.tgz
and http://pliant.cx/archive/pliant-79pre1.zip for you.
The problem is in the 'module' and 'style' instructions handling in .page
When I correct the problem in some place, it raises other problems elsewhere,
which is the sign of an overall bad design.
What I've done in this pre release also does not cover a huge security issue
with ultrasafe style.
Aslo it should solve you doc.style problems.
|Message posted by marcus on 2002/11/26 16:19:04
1- That infamous glitch in which the colours of a customized style are not
propagated to the dyncamically created pages (i.e., created via 'note' or
'button', and other pages within these ones) is reborn in 79-pre1.
2- 'sample' works.
|Message posted by maybe Marcus on 2002/11/26 16:42:54
|pliant.cx reports an error in
Moreover, when accessing http://pliant.cx/pliant/protocol/http/index.page,
There is a bug in the dynamic page /pliant/protocol/http/index.page.
Failed to parse token �left_zero_is_at "/pliant/protocol/http/index.page" 0 1� (0)
parse /pliant/protocol/http/index.page 5 5
service HTTP request
|Message posted by hubert.tonneau on 2002/11/26 18:01:10
|> That infamous glitch in which the colours of a customized style are not
> propagated to the dyncamically created pages
Even worse: no style at all, excepte when the style instruction is followed
by a comment, just like on /pliantdocs/ home page, which should be forbidden.
I've uploade http://pliant.cx/archive/pliant-79pre2.tgz and
http://pliant.cx/archive/pliant-79pre2.zip for you.
I'll try to write an explaination about the all problem because it might work
discuss a bit since there seem to be no clear solution (or rather I have not
found a fully clean solution)
|Message posted by marcus on 2002/11/26 18:28:44
|Yes. 79pre2 has solved those problems I mentioned in my message.
Hubert, could you then upoad it to the PDI documentation host?
|Message posted by hubert.tonneau on 2002/11/26 20:00:21
|> Hubert, could you then upoad it to the PDI documentation host?
You can do all that on your own. Here how to proceed.
Do the new tarball locally through something like:
tar -zcv -f /tmp/upgrade.tgz /pliant/binary/*.exe /pliant/index.page /pliant/pliant/
then upload the upgrade.tgz in the 'file:/boot/' directory of 'extra1.fullpliant.org'
It will be installed automatically.
Also you then have 2 hours to connect again to 'extra1.fullpliant.org' and
delete the 'downgrade.tgz' file in 'file:/boot/' directory. If not, the
server will considere that the new tree was broken, so you lost control,
so it will reverse everything automatically in order to bring the machine
back to something working.
Just try it since 'extra1.fullpliant.org' is a logical computer, so should
you loose control, I still should be abble to bring the system again through
connecting to the 'server5.heliogroup.fr' real machine.
|Message posted by maybe Marcus on 2002/11/26 21:07:58
|> Do the new tarball locally through something like:
> tar -zcv -f /tmp/upgrade.tgz /pliant/binary/*.exe /pliant/index.page
How to I run linux commands on extra1.fullpliant.org using the browser? I tried
to click on the link 'Root shell' at
but nothing comes up.
|Message posted by hubert.tonneau on 2002/11/26 21:51:16
|> How to I run linux commands on extra1.fullpliant.org using the browser?
You can't get a shell, and you don't need to.
You have to do the tarball on your own machine, at your office or home,
then upload it to extra1.fullpliant.org with the very precise name
'upgrade.tgz' in directory 'file:/boot/' and you will be abble to do that
thanks to the Pliant file browser on extra1.fullpliant.org
The way to execute commands on 'extra1.fullpliant.org' is using Pliant
interpreter. They can be either Pliant command or some of the very fiew
Unix commands that are available through FullPliant without a Debian
embedded system, such as 'tar', and these are accessed using the Pliant
'execute' instruction. Also, once again, you don't need to execute any
command on 'extra1.fullpliant.org' in order to upgrade: just upload the
right file at the right place.
|Message posted by maybe MarcusAlso you then have 2 hours to connect again to 'extra1.fullpliant.org' and
Marcus on 2002/11/27 03:32:04
|> Also you then have 2 hours to connect again to 'extra1.fullpliant.org' and
> delete the 'downgrade.tgz' file in 'file:/boot/' directory. If not,
I didn't quite get this part.
I have uloaded upgrade.tgz to the 'file:/boot/' I think more than two hours ago.
But still there is no 'downgrade.tgz' there. And does not seem that the
package has been automatically installed so far.
|Message posted by hubert.tonneau on 2002/11/27 09:17:24
|Ok, the feature is available only in FullPliant systems, and I had forgotten
to define that logical computers are FullPliant systems. It's corrected now.
In case you would like to view the code, it's defined (at a poor place) in
'apply_uploaded_file' method in module /pliant/appli/file_browser.pli
|Message posted by maybe Marcus on 2002/11/27 14:31:15
|Something strange is going on: connected to extra1.fullpliant.org, and browsing
its file system, I tried to upload upgrade.tgz from my local machine to extra1.
The process starts but then hangs (or it seems). I stoped it, then tried to do
the same thing via tree synchronizing. Again, it is taking too long...
I have to go out now. I will not stop the synchronizing and lets see what happens.
|Message posted by hubert.tonneau on 2002/11/27 17:09:57
|Sorry: the 'upgrade.tgz' process does not work on logical computers at the
moment. I have to correct it and check it.
|Message posted by maybe Marcus on 2002/11/27 19:33:08
|Meanwhile, could you please upload release 79pre2 on extra1 yourself.
I have some colleagues in Brazil who are interested in looking over the recent
documentation regarding the database engine.
Another thing: just reminding you to fix that glitch on the forum (the listing
of the more recent posted messages). Perhaps add it to 79pre2.
|Message posted by hubert.tonneau on 2002/11/27 22:29:31
|> Meanwhile, could you please upload release 79pre2 on extra1 yourself.
> Another thing: just reminding you to fix that glitch on the forum (the listing
> of the more recent posted messages). Perhaps add it to 79pre2.
It's part of my reviewing of the overall forum application as a switch to a
better overall organization for applying changes (from me and contributors)
to Pliant project, and publishing new releases.