gendl issueshttps://gitlab.common-lisp.net/gendl/gendl/-/issues2017-04-10T15:43:27Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/145PDF->PNG fails on LW, SBCL2017-04-10T15:43:27ZDave CooperPDF->PNG fails on LW, SBCL*Created by: genworks*
PDF stream is opened in wrong mode (e.g. ascii vs binary) for png and jpeg output-formats.
**Imported comments:**
*By genworks on 2012-02-10 04:07:08 UTC*
This is now fixed for LispWorks and SBCL. There is s...*Created by: genworks*
PDF stream is opened in wrong mode (e.g. ascii vs binary) for png and jpeg output-formats.
**Imported comments:**
*By genworks on 2012-02-10 04:07:08 UTC*
This is now fixed for LispWorks and SBCL. There is still redundent file I/O for PDF->PNG and PDF->JPEG, and the file I/O seems to be slow in SBCL, so this redundancy needs to be addressed. https://gitlab.common-lisp.net/gendl/gendl/-/issues/143Tasty zoom-in and zoom-out2017-04-10T15:43:27ZDave CooperTasty zoom-in and zoom-out*Created by: teodor-gelu*
The zoom-in and zoom-out image are reversed :
image viewmag- is zoom-in and
image viewmag+ is zoom-out.
**Imported comments:**
*By genworks on 2012-03-30 14:46:07 UTC*
This is apparently resolved, c...*Created by: teodor-gelu*
The zoom-in and zoom-out image are reversed :
image viewmag- is zoom-in and
image viewmag+ is zoom-out.
**Imported comments:**
*By genworks on 2012-03-30 14:46:07 UTC*
This is apparently resolved, courtesy Teodor-Gelu. https://gitlab.common-lisp.net/gendl/gendl/-/issues/142VRML cone2017-04-10T15:43:27ZDave CooperVRML cone*Created by: teodor-gelu*
The vrml export of a geom-base cone object is inconsistent:
see the Genworks-GDL / documentation / unified-doc / examples / shock-absorber-v0.3
**Imported comments:**
*By genworks on 2012-02-11 21:1...*Created by: teodor-gelu*
The vrml export of a geom-base cone object is inconsistent:
see the Genworks-GDL / documentation / unified-doc / examples / shock-absorber-v0.3
**Imported comments:**
*By genworks on 2012-02-11 21:19:46 UTC*
Closing this because it is redundant with Issue #9. https://gitlab.common-lisp.net/gendl/gendl/-/issues/141Does not build on SBCL: missing components2017-04-10T15:43:27ZDave CooperDoes not build on SBCL: missing components*Created by: quicklisp*
Here are some example failure logs:
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-all_gdl-all.txt
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-surf_gdl-sur...*Created by: quicklisp*
Here are some example failure logs:
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-all_gdl-all.txt
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-surf_gdl-surf.txt
http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-build_gdl-build.txt
There are others, if it helps.
**Imported comments:**
*By genworks on 2012-03-22 21:20:06 UTC*
Hi Zach,
Thank you for trying these builds again.
Are these current build logs? I just did a clean build of these
systems (SBCL 1.0.55 MacOS) from the current github repository, and I
am not seeing any errors. The gdl-cl-typesetting-ql-patch.asd is
definitely in the repository (that's the error in the first and third
logs), and the second log is showing style-warnings (e.g. IGNORE
declaration for unknown variable &KEY) for methods.lisp, which for
sure are not in the current version of that file in the repository any
more.
Maybe there is something else wrong with my configuration? Please let me know.
Best Regards,
-dave
On Thu, Mar 22, 2012 at 2:06 PM, Zach Beane
<reply@reply.github.com>
wrote:
> Here are some example failure logs:
>
> http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-all_gdl-all.txt
>
> http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-surf_gdl-surf.txt
>
> http://dl.dropbox.com/u/41993869/quicklisp/fails/fail_genworks-gdl_gdl-build_gdl-build.txt
>
> There are others, if it helps.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/genworks/Genworks-GDL/issues/19
--
Genworks Support
support@genworks.com
*By genworks on 2012-03-23 14:00:13 UTC*
Hi Zach,
Thank you for trying these builds again.
Are these current build logs? I just did a clean build of these
systems (SBCL 1.0.55 MacOS) from the current github repository, and I
am not seeing any errors. The gdl-cl-typesetting-ql-patch.asd is
definitely in the repository (that's the error in the first and third
logs), and the second log is showing style-warnings (e.g. IGNORE
declaration for unknown variable &KEY) for methods.lisp, which for
sure are not in the current version of that file in the repository any
more.
Maybe there is something else wrong with my configuration? Please let me know.
Best Regards,
-dave
*By quicklisp on 2012-03-23 19:55:12 UTC*
Must have been a temporary glitch, things build fine now.
What's the duplicate tree in 1580-freeze? Should it be ignored?
*By genworks on 2012-03-23 21:00:50 UTC*
>
> What's the duplicate tree in 1580-freeze? Should it be ignored?
>
Yes, it should be ignored. I will get rid of it soon.
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By genworks on 2012-03-30 14:45:47 UTC*
Must add an ASD system for :genworks-gdl -- genworks-gdl.asd to make it intuitive for folks to load Genworks-GDL with quicklisp. https://gitlab.common-lisp.net/gendl/gendl/-/issues/140Allow layout of form-controls from other objects in tree2015-03-31T02:17:23ZDave CooperAllow layout of form-controls from other objects in tree*Created by: genworks*
As gdlAjax works currently, the form-controls have to be local to the sheet (or sheet-section) where they are laid out. It should be possible to use form-controls which are in child objects or other objects (e.g. ...*Created by: genworks*
As gdlAjax works currently, the form-controls have to be local to the sheet (or sheet-section) where they are laid out. It should be possible to use form-controls which are in child objects or other objects (e.g. passed in as inputs) and laid out in the current sheet. It should also be possible to construct HTML strings using form-controls from current sheet, and pass those HTML strings into other objects to be laid out (or as inner-html input).
This will require change to form-control-processor, and should be backward compatible since it is an extension of the way things work currently.
**Imported comments:**
*By genworks on 2012-03-30 14:44:58 UTC*
this is committed, needs to be monitored to make sure it doesn't cause other strange behavior.
NOTE that main-view in skeleton-ui-element HAS BEEN CHANGED to inner-html.https://gitlab.common-lisp.net/gendl/gendl/-/issues/139make-gdl-app updated for this release2015-03-31T02:17:23ZDave Coopermake-gdl-app updated for this release*Created by: genworks*
Enhance the :gdl-build package to support a compatible make-gdl-app function as compatible as possible to the 1580 make-gdl-app. Also used for internal builds. Also automate the generating of customer license file...*Created by: genworks*
Enhance the :gdl-build package to support a compatible make-gdl-app function as compatible as possible to the 1580 make-gdl-app. Also used for internal builds. Also automate the generating of customer license files for proprietary customers. https://gitlab.common-lisp.net/gendl/gendl/-/issues/138Website upgraded to support customer needs2015-03-31T02:17:23ZDave CooperWebsite upgraded to support customer needs*Created by: genworks*
Website application requires product configurator, download wizard, and customer license file manager. *Created by: genworks*
Website application requires product configurator, download wizard, and customer license file manager. https://gitlab.common-lisp.net/gendl/gendl/-/issues/137GWL (gdlAjax) replaces _both_ innerHTML and js-to-eval2015-03-31T02:17:23ZDave CooperGWL (gdlAjax) replaces _both_ innerHTML and js-to-eval*Created by: genworks*
As reported by Reinier van Dijk --- these should be separate conditionals, with separate conditional replacement code in the gdl-ajax.js javascript.
**Imported comments:**
*By genworks on 2013-01-12 22:...*Created by: genworks*
As reported by Reinier van Dijk --- these should be separate conditionals, with separate conditional replacement code in the gdl-ajax.js javascript.
**Imported comments:**
*By genworks on 2013-01-12 22:46:45 UTC*
We need some examples of each combination. It seems to me that the js-to-eval needs to be evaluated any time the innerHTML is refreshed, whether or not the js-to-eval is actually dirty (i.e. :unbound) or not after the gdlAjax submission and associated fields are bashed and function is called. This is because the js-to-eval is typically intended for e.g. jQuery widgets which need to be initialized whenever the html is rendered.
This brings into question whether there is a real need for the js-always-to-eval ? When is that ever really necessary?
Note that in demos/newsite/, both of these are used. But after we look through some simple examples I have a feeling that we will determine that the js-always-to-eval is really redundant. Let's see where this goes.
*By genworks on 2013-01-12 22:57:28 UTC*
@reiniervandijk You may be interested to follow this Issue.
*By reiniervandijk on 2013-01-15 12:25:41 UTC*
Think of the opposite. If js-to-eval becomes :unbound, would you like to have :inner-html evaluated? No, you *don't*. In case of the SVG canvas, an :unbound js-to-eval (like add-line) will 'drag' the inner-html along with it right now, resulting in a new canvas being created every time. I think you need to clearly offer the user all capabilities that one would like to have. Suggestion:
1. keep js-always-to-eval: this can be the initialization code if innerHTML changes. One may also call it js-on-init. Another option would be to define js-before-init **AND** js-after-init. Make sure to tell users that you typically expect static strings here, without dependencies.
2. keep js-to-eval: this should normally be used for js that is dis-related to init events.
3. compute js-all-to-eval with this logic:
* if both js-always-to-eval AND innerHTML :unbound **AND** js-to-eval :unbound, then
```(string-append (the js-always-to-eval) (the js-to-eval))```
* otherwise 1 on the 2, or none.https://gitlab.common-lisp.net/gendl/gendl/-/issues/136gdl-demos does not build due to package error2015-03-31T02:17:22ZDave Coopergdl-demos does not build due to package error*Created by: quicklisp*
I get "The name "SURF" does not designate any package" when trying to build today.
**Imported comments:**
*By genworks on 2012-05-06 15:57:56 UTC*
Is that when building GDL-demos from a clean slate, or aft...*Created by: quicklisp*
I get "The name "SURF" does not designate any package" when trying to build today.
**Imported comments:**
*By genworks on 2012-05-06 15:57:56 UTC*
Is that when building GDL-demos from a clean slate, or after already building some other systems?
Yours Truly,
Dave Cooper
On May 6, 2012, at 10:00 AM, Zach Beane<reply@reply.github.com> wrote:
> I get "The name "SURF" does not designate any package" when trying to build today.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/genworks/Genworks-GDL/issues/26
*By quicklisp on 2012-05-06 16:01:25 UTC*
That's building gdl-demos independently of anything else.
*By genworks on 2012-05-06 16:36:01 UTC*
This should be fixed with latest version pushed into git. Note that there is still a potential issue of order-dependency when loading any form with gdl:define-package -- this package definition changes when :surf package is loaded (maybe not such a great idea). gdl:define-package definition changes to include (:use :surf) in the package definition. This causes some potential issues if systems are loaded in an unexpected order. When I can nail down the issue a bit more concretely, I will build in some logic to avoid the package error in those cases. As long as standard Quicklisp build tests do not exhibit the error right now then I don't consider it top priority.
*By quicklisp on 2012-05-08 14:25:58 UTC*
FYI, there's a similar error in the gdl-site system.
*By genworks on 2012-05-08 17:49:13 UTC*
Thank you. I just deleted that system because it is redundant - :gdl-demos includes the files from :gdl-site and there would be no reason to load :gdl-site independently of :gdl-demos.
*By genworks on 2012-05-14 16:53:00 UTC*
These package issues should be all better now. https://gitlab.common-lisp.net/gendl/gendl/-/issues/135VRML broken in tasty2015-03-31T02:17:22ZDave CooperVRML broken in tasty*Created by: aclark2*
After recent commits, VRML is now broken in tasty (but works in ta2).
Allegro console shows the following output:
4-aserve-worker: 05/14/12 - 08:10:59 - while processing command "GET /sessions/103d35b74b3/viewpor...*Created by: aclark2*
After recent commits, VRML is now broken in tasty (but works in ta2).
Allegro console shows the following output:
4-aserve-worker: 05/14/12 - 08:10:59 - while processing command "GET /sessions/103d35b74b3/viewport/model.wrl HTTP/1.1"
got error symbol-value got 2 args, wanted 1 arg.
I believe everything was still working fine on Friday (05/11).
**Imported comments:**
*By genworks on 2012-05-14 16:52:30 UTC*
This should be fixed now with latest push. https://gitlab.common-lisp.net/gendl/gendl/-/issues/134Fails to build when trying to find "QL" package2015-03-31T02:17:21ZDave CooperFails to build when trying to find "QL" package*Created by: quicklisp*
None of the systems build any more, as there's a reference to QL:FOO in the sources. Quicklisp isn't available as a dependency for libraries to use, sorry.
**Imported comments:**
*By genworks on 2012-05-17 15...*Created by: quicklisp*
None of the systems build any more, as there's a reference to QL:FOO in the sources. Quicklisp isn't available as a dependency for libraries to use, sorry.
**Imported comments:**
*By genworks on 2012-05-17 15:58:02 UTC*
Thank you, this is cleaned up now. https://gitlab.common-lisp.net/gendl/gendl/-/issues/133Gendl-specific colorizing needed in glime mode2015-03-31T02:17:21ZDave CooperGendl-specific colorizing needed in glime mode*Created by: genworks*
slime/glime mode from dist/emacs/gdl.el does not fully colorize Gendl-specific operators, such as "the," "the-object," "the-child."
color-theme implementation needs to be customized to highlight these operators....*Created by: genworks*
slime/glime mode from dist/emacs/gdl.el does not fully colorize Gendl-specific operators, such as "the," "the-object," "the-child."
color-theme implementation needs to be customized to highlight these operators.
**Imported comments:**
*By genworks on 2012-05-29 09:26:39 UTC*
Note that the legacy gdl:set-colors are available by commenting out the "color-theme" lines and adding
(gdl:set-colors)
in the emacs/gdl.el
https://gitlab.common-lisp.net/gendl/gendl/-/issues/132Safari redirects to non-existent session2015-03-31T02:17:20ZDave CooperSafari redirects to non-existent session*Created by: genworks*
Safari tends to redirect toplevel GWL URLs to the previous session ID, which can be timed out or will be non-existent if the Gendl session has been restarted. The make-gwl-object needs to handle this in a reasonab...*Created by: genworks*
Safari tends to redirect toplevel GWL URLs to the previous session ID, which can be timed out or will be non-existent if the Gendl session has been restarted. The make-gwl-object needs to handle this in a reasonable way. https://gitlab.common-lisp.net/gendl/gendl/-/issues/131Various package-related build failures recently2015-03-31T02:17:20ZDave CooperVarious package-related build failures recently*Created by: quicklisp*
Here are some failures I've gotten recently for a few GDL systems:
::: genworks-gdl from git://github.com/genworks/Genworks-GDL.git
=================================
FAIL: "fail_genworks-gdl_gdl-aer...*Created by: quicklisp*
Here are some failures I've gotten recently for a few GDL systems:
::: genworks-gdl from git://github.com/genworks/Genworks-GDL.git
=================================
FAIL: "fail_genworks-gdl_gdl-aero-demo-1_gdl-aero-demo-1.txt"
=================================
unhandled LOAD-SYSTEM-DEFINITION-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C13C3}>: Error while trying to load definition for system gdl-surf from pathname /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/surf/gdl-surf.asd: don't recognize component type LISP
=================================
FAIL: "fail_genworks-gdl_gdl-build_gdl-build.txt"
=================================
unhandled SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C1363}>: The name "GDL-USER" does not designate any package.
=================================
FAIL: "fail_genworks-gdl_gdl-translators_gdl-translators.txt"
=================================
;
; caught ERROR:
; READ error during COMPILE-FILE: Package GWL does not exist.Line: 23, Column: 19, File-Position: 877Stream: #<SB-SYS:FD-STREAM for "file /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/gdl/apps/translators/xml/source/package.lisp" {1004A47B13}>
=================================
FAIL: "fail_genworks-gdl_gdl-wind-demo-1_gdl-wind-demo-1.txt"
=================================
unhandled SB-KERNEL:SIMPLE-PACKAGE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {10030C13C3}>: The name "GDL-USER" does not designate any package.
=================================
FAIL: "fail_genworks-gdl_gdl-xml_gdl-xml.txt"
=================================
;
; caught ERROR:
; READ error during COMPILE-FILE: Package GWL does not exist.Line: 23, Column: 19, File-Position: 877Stream: #<SB-SYS:FD-STREAM for "file /home/xach/quicklisp-controller/dist/build-cache/genworks-gdl/8e28990e4d68d2512cddc755e8e165001dd3104e/genworks-gdl-20120807-git/gdl/apps/translators/xml/source/package.lisp" {1004A3DBD3}>
I'm using a recent SBCL on AMD64.
**Imported comments:**
*By genworks on 2012-09-10 02:05:08 UTC*
Thank you for the report. These failed .asd files have been either removed (as unecessary) or fixed up with correct dependencies. I don't see any other obvious failure candidates, but if there are any please let me know and I will try to jump on them right away.
I know we still have a slew of style-warnings to clean up.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/130Apparent memory leak on SBCL2015-03-31T02:17:20ZDave CooperApparent memory leak on SBCL*Created by: genworks*
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
http://localhost:9000/tasty
and drawing a robot will consume a large amount of heap, simply reloading this p...*Created by: genworks*
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
http://localhost:9000/tasty
and drawing a robot will consume a large amount of heap, simply reloading this page several times will exhaust the SBCL heap. On Allegro CL it is using just a fraction of the memory and garbage collection always seems to bring the used oldspace back to baseline.
So there is some kind of memory leak going on with the SBCL platform. I need to develop a more standardized way of testing for this but in the meantime if anyone has any clues, I will be very interested!
Note that you can clear all web sessions with
(gwl:clear-all-instances)
So, in theory you should be able to make unlimited web pages and clear them with (gwl:clear-all-instances), and garbage collection should bring things back to baseline.
EDIT: A programmatic way to replicate this is:
(in-package :gdl-user)
(dotimes (n 1000) (net.aserve.client:do-http-request "http://localhost:9000/newsite") (gwl:clear-all-instances))
You will exhaust your heap for sure. If you want to stop before exhausting the heap just do it 50 or 100 instead of 1000 times. Then perhaps it will be possible to examine the heap and see what is taking up all the space.
**Imported comments:**
*By genworks on 2012-09-20 13:50:53 UTC*
One hunch is that this may have to do with use of weak hash tables in parts of the gwl package/module. We use glisp:make-weak-hash-table which maps into certain options on SBCL which may not be correct. I think we use :key-or-value and perhaps we should use :key-and-value. Just an idea, have not had time to test this out yet.
*By genworks on 2012-10-11 23:21:58 UTC*
This is apparently fixed now. Indeed the issue was our implementation of glisp:make-weak-hash-table as defined in
gdl/base/common/genworks.lisp
For SBCL we were using
(make-hash-table :weakness :key-or-value)
and we really need the entries to disappear when only the value becomes garbage, so the correct option is:
(make-hash-table :weakness :key-and-value)
Should have just found 10 minutes to look at this 21 days ago -- that's about how long it took to isolate and fix the problem...
I am committing the fix now; it should make it into the October 2012 Quicklisp release.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/129Apparent memory leak on SBCL2015-03-31T02:17:19ZDave CooperApparent memory leak on SBCL*Created by: genworks*
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
http://localhost:9000/tasty
and drawing a robot will consume a large amount of heap, simply reloading this p...*Created by: genworks*
This is possibly related to portable allegroserve.
Bringing up a standard Gendl web page such as
http://localhost:9000/tasty
and drawing a robot will consume a large amount of heap, simply reloading this page several times will exhaust the SBCL heap. On Allegro CL it is using just a fraction of the memory and garbage collection always seems to bring the used oldspace back to baseline.
So there is some kind of memory leak going on with the SBCL platform. I need to develop a more standardized way of testing for this but in the meantime if anyone has any clues, I will be very interested!
Note that you can clear all web sessions with
(gwl:clear-all-instances)
So, in theory you should be able to make unlimited web pages and clear them with (gwl:clear-all-instances), and garbage collection should bring things back to baseline.
EDIT: A programmatic way to replicate this is:
(in-package :gdl-user)
(dotimes (n 1000) (net.aserve.client:do-http-request "http://localhost:9000/newsite") (gwl:clear-all-instances))
You will exhaust your heap for sure. If you want to stop before exhausting the heap just do it 50 or 100 instead of 1000 times. Then perhaps it will be possible to examine the heap and see what is taking up all the space.
**Imported comments:**
*By genworks on 2012-10-11 23:19:17 UTC*
This is apparently fixed now. The issue was our implementation of glisp:make-weak-hash-table as defined in
gdl/base/common/genworks.lisp
For SBCL we were using
(make-hash-table :weakness :key-or-value)
and we really need the entries to disappear when only the value becomes garbage, so the correct option is:
(make-hash-table :weakness :key-and-value)
I am committing the fix now; it should make it into the October 2012 Quicklisp release.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/128Breakage due to ASDF package changes2015-03-31T02:17:19ZDave CooperBreakage due to ASDF package changes*Created by: fare*
Recent versions of ASDF do not export DIRECTORY-PATHNAME-P or any utilities anymore.
This breaks Genworks-GDL.
The fix is to either
1- use ASDF-UTILS that exports all these utilities, or
2- use internal symbols ...*Created by: fare*
Recent versions of ASDF do not export DIRECTORY-PATHNAME-P or any utilities anymore.
This breaks Genworks-GDL.
The fix is to either
1- use ASDF-UTILS that exports all these utilities, or
2- use internal symbols like ASDF::DIRECTORY-PATHNAME-P if you really can't or won't depend on ASDF-UTILS.
Please test with a new ASDF (such as 2.25), without loading any system-provided ASDF via require.
My apologies for the breakage.
**Imported comments:**
*By genworks on 2012-10-11 17:31:13 UTC*
Ok, I think this is fixed up now. So does this mean that ADSF 2.25 will ship with the October Quicklisp?
*By quicklisp on 2012-10-11 17:34:37 UTC*
No, Quicklisp does not ship updates to ASDF.
*By quicklisp on 2012-10-11 17:41:53 UTC*
It does mean that as ASDF 2.25 is available to people through implementation updates or otherwise, Genworks-GDL will continue to work.
*By quicklisp on 2012-10-11 18:22:43 UTC*
I still can't build things. I'm not sure I understand the failure mode, but in looking at the diff, did you just do a global replacement of `asdf:` with `asdf-utilities:`? That won't work - there's no `asdf-utilities:*central-registry*` or `asdf-utilities:defsystem` or `asdf-utilities:map-systems`, those remain part of ASDF.
*By quicklisp on 2012-10-11 18:46:15 UTC*
Ooops. I see the problem. `ASDF-UTILITIES` is a nickname for `ASDF`. You should, I believe, be using `ASDF-UTILS` instead.
*By fare on 2012-10-11 19:52:51 UTC*
I should probably delete the obsolete name ASDF-UTILITIES from ASDF.
Xach, does anyone use that name in quicklisp?
*By quicklisp on 2012-10-11 19:55:35 UTC*
I'll modify my local ASDF, build the world, and let you know.
*By genworks on 2012-10-11 20:59:49 UTC*
Ok I understand now -- asdf-utils is a separate Quicklisp system. Somehow I had the idea it was just a package included with asdf, then confounded things by using asdf-utilities instead of asdf-utils --- then noticed that everything was exported from this asdf-utilities and somehow got the weird idea that everything of asdf should be accessed through that package now...
Anyway this will all be re-sanitized after dinner and sorry for the confusion...
*By quicklisp on 2012-10-11 23:13:18 UTC*
For what it's worth, no projects (aside from this temporary Genworks GDL issue) use the ASDF-UTILITIES nickname.
*By genworks on 2012-10-11 23:30:59 UTC*
Thank you both for all the feedback.
Everything should be buildable now.
Please let me know if there are still any build issues (even ones unrelated to this ASDF issue).
*By genworks on 2012-12-20 21:51:49 UTC*
This should no longer be an issue. I am closing the issue now. https://gitlab.common-lisp.net/gendl/gendl/-/issues/127regression in quicklisp 2012-11-25: System "gdl-robot" not found2015-03-31T02:17:18ZDave Cooperregression in quicklisp 2012-11-25: System "gdl-robot" not found*Created by: avodonosov*
(ql:quickload :genworks-gdl) fails in quicklisp 2012-11-25 on lisps, which were working in the previous quicklisp, e.g. SBCL.
new log:
http://cl-test-grid.appspot.com/blob?key=801816
previous log:
http://cl-t...*Created by: avodonosov*
(ql:quickload :genworks-gdl) fails in quicklisp 2012-11-25 on lisps, which were working in the previous quicklisp, e.g. SBCL.
new log:
http://cl-test-grid.appspot.com/blob?key=801816
previous log:
http://cl-test-grid.appspot.com/blob?key=550328
**Imported comments:**
*By genworks on 2012-11-30 03:16:31 UTC*
Hmmm that is surprising, because gdl-robot.asd is there in demos/robot/ in
github since 10 days ago...
Is cl-test-grid doing build tests now? I thought Quicklisp does those
before release, and cl-test-grid is more about runtime testing?
In any case I cannot replicate this with the current github version. Is
there anything we can do to try to remediate this short of waiting for next
month's Quicklisp release?
On Thu, Nov 29, 2012 at 10:11 PM, Anton Vodonosov
<notifications@github.com>wrote:
> (ql:quickload :genworks-gdl) fails in quicklisp 2012-11-25 on lisps, which
> were working in the previous quicklisp, e.g. SBCL.
>
> new log:
> http://cl-test-grid.appspot.com/blob?key=801816
>
> previous log:
> http://cl-test-grid.appspot.com/blob?key=550328
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/40>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By avodonosov on 2012-11-30 03:25:07 UTC*
I don't know why it happens. Maybe it's quicklisp bug - when I do (ql:quickload :genworks-gdl) quicklisp doesn't even seem to download archive from internet, just reports an errror.
To reporduce it it's enough to just run (ql:quickload :genworks-gdl)
Xach tests that asfd compilation works for all the systems on SBCL on this machine before releasing quicklisp.
cl-test-grid then collects tests (including ql:quickload of every ASDF system in quicklisp) on various CL implementations.
*By genworks on 2012-11-30 03:39:31 UTC*
Welp, it looks like gdl-robot.asd didn't make it into systems.txt,
presumably because the ql:quickload of that individual .asd file failed,
because it does not have the proper dependencies (it should depend on
:gdl-gwl-graphics).
I'll make that fix into github now, but it is unfortunate that there
doesn't seem to be a way to fix this for standard Quicklisp users until
next month...
On Thu, Nov 29, 2012 at 10:25 PM, Anton Vodonosov
<notifications@github.com>wrote:
> I don't know why it happens. Maybe it's quicklisp bug - when I do
> (ql:quickload :genworks-gdl) quicklisp doesn't even seem to download
> archive from internet, just reports an errror.
>
> To reporduce it it's enough to just run (ql:quickload :genworks-gdl)
>
> Xach tests that asfd compilation works for all the systems on SBCL on this
> machine before releasing quicklisp.
>
> cl-test-grid then collects tests (including ql:quickload of every ASDF
> system in quicklisp) on various CL implementations.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/40#issuecomment-10876977>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By genworks on 2012-11-30 03:46:43 UTC*
So the immediate local fix would be:
(pushnew
".../quicklisp/dists/quicklisp/software/genworks-gdl-20121125-git/"
ql:*local-projects-directories*)
(ql:register-local-projects)
(ql:quickload :genworks-gdl)
On Thu, Nov 29, 2012 at 10:39 PM, Dave Cooper <david.cooper@genworks.com>wrote:
>
>
> Welp, it looks like gdl-robot.asd didn't make it into systems.txt,
> presumably because the ql:quickload of that individual .asd file failed,
> because it does not have the proper dependencies (it should depend on
> :gdl-gwl-graphics).
>
>
> I'll make that fix into github now, but it is unfortunate that there
> doesn't seem to be a way to fix this for standard Quicklisp users until
> next month...
>
>
>
>
>
> On Thu, Nov 29, 2012 at 10:25 PM, Anton Vodonosov <
> notifications@github.com> wrote:
>
>> I don't know why it happens. Maybe it's quicklisp bug - when I do
>> (ql:quickload :genworks-gdl) quicklisp doesn't even seem to download
>> archive from internet, just reports an errror.
>>
>> To reporduce it it's enough to just run (ql:quickload :genworks-gdl)
>>
>> Xach tests that asfd compilation works for all the systems on SBCL on
>> this machine before releasing quicklisp.
>>
>> cl-test-grid then collects tests (including ql:quickload of every ASDF
>> system in quicklisp) on various CL implementations.
>>
>> —
>> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/40#issuecomment-10876977>.
>>
>>
>
>
>
> --
>
> My Best,
>
> Dave Cooper, Genworks Support
> david.cooper@genworks.com, dave.genworks.com(skype)
> USA: 248-327-3253(o), 1-248-330-2979(mobile)
> UK: 0191 645 1699
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By genworks on 2012-12-20 21:51:27 UTC*
This should be resolved by the December 2012 Quicklisp. Closing the issue now. https://gitlab.common-lisp.net/gendl/gendl/-/issues/126source files encodings2015-03-31T02:17:18ZDave Coopersource files encodings*Created by: avodonosov*
The encoding used by lisp implementation to read source files is often depends on environment.
Example, when GDL doesn't build because the default encoding used by lisp implementation is not UTF-8:
http://cl-tes...*Created by: avodonosov*
The encoding used by lisp implementation to read source files is often depends on environment.
Example, when GDL doesn't build because the default encoding used by lisp implementation is not UTF-8:
http://cl-test-grid.appspot.com/blob?key=792731
If you want the sources to be more reliably build on systems were UTF8 is not default encoding, you may specify the encoding in your .asdf files:
```
#+asdf-unicode :encoding #+asdf-unicode :utf-8
```
The chapter about source file encoding in ASDF manual:
http://common-lisp.net/project/asdf/asdf/Miscellaneous-additional-functionality.html#Miscellaneous-additional-functionality
P.S. you may find build status of genworks-gdl and other libraries on different lisps here:
http://common-lisp.net/project/cl-test-grid/library/
**Imported comments:**
*By genworks on 2012-11-30 16:14:55 UTC*
Dear Anton,
Thank you very much for this report and for your great work.
The reports will give us a valuable head-start on getting our library to
work with as many Lisps as possible. Currently we are supposed to work on
ACL, LispWorks, and SBCL, so I will focus on getting those straightened out
first of all. I will keep you apprised on progress.
By the way I am still trying to figure out how to move forward with CLF,
and will let you know about any major progress on that front as well.
Regards
Dave
On Fri, Nov 30, 2012 at 9:58 AM, Anton Vodonosov
<notifications@github.com>wrote:
> The condising used by lisp implementation to read source files is often
> depends on environment.
> If you want the sources to be more reliably build on systems were UTF8 is
> not default encoding, you may specify the encoding in your .asdf files:
>
> #+asdf-unicode :encoding #+asdf-unicode :utf-8
>
> The chapter about source file encoding in ASDF manual:
>
> http://common-lisp.net/project/asdf/asdf/Miscellaneous-additional-functionality.html#Miscellaneous-additional-functionality
>
> P.S. you may find build status of genworks-gdl and other libraries on
> different lisps here:
> http://common-lisp.net/project/cl-test-grid/library/
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/41>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By genworks on 2012-12-13 15:28:27 UTC*
Hi Anton,
I don't think we really need our source files to be in UTF-8. It might be simpler if we can just convert all our files into a more basic encoding (normal ASCII, right?) I think some files got into UTF-8 because we have some examples with Chinese characters in there. But those examples are not necessary for basic Gendl to build and function.
What do you think?
*By avodonosov on 2012-12-13 16:24:11 UTC*
Restricting the source code to basic-latin will work too.
On the other hand most of the CL implementations (including the recent SBCL releases) support utf-8 and have suficiently recent ASDF so that the #+asdf-unicode conditionalized part of .asd will be in effect.
So, what of the two solutinos to chose is mostly what is more convenient to you:
tranfrom the files to basic latin, or add the #+asd-unicode specification to the ASDF system which includes these examples.
*By genworks on 2012-12-18 04:18:20 UTC*
I believe the offending files are now converted to basic-latin (latin1 or iso-8859).
FYI, in order to Gendl (genworks-gdl) to be expected to build in CLs other than Allegro, LispWorks, and SBCL, we still have to add platform-specific directives to the several genworks.lisp files distributed throughout the codebase (there are eight of them, as follows:
./build/source/genworks.lisp
./gdl/apps/translators/xml/source/genworks.lisp
./gdl/apps/yadd/source/genworks.lisp
./gdl/base/common/genworks.lisp
./gdl/cl-lite/source/genworks.lisp
./gdl/geom-base/prereqs/source/genworks.lisp
./gdl/gwl/source/genworks.lisp
./regression/utils/source/genworks.lisp
it is not necessary for all of these to be updated for a basic build to work -- pretty much only
gdl/base/common/genworks.lisp
gdl/cl-lite/source/genworks.lisp
gdl/geom-base/prereqs/source/genworks.lisp
gdl/gwl/source/genworks.lisp
will be enough for the core essentials to build and function.
Also, portableallegroserve.
).
*By genworks on 2012-12-20 21:50:33 UTC*
I'm closing this issue now. Please re-open it or let me know if any of the encodings continue to give problems. By the way note that we have recently ported to CCL, so we should build and run on all supported CCL platforms. You need the latest Sourceforge git of portableaserve and the latest github of Genworks-gdl for it to work (or just wait for the December 2012 Quicklisp release of everything).
*By avodonosov on 2012-12-20 21:52:36 UTC*
I know, I read CCL devel.
We will see the difference when next quicklisp is out and cl-test-gird will collect results from it.
*By avodonosov on 2013-01-13 17:00:39 UTC*
Most of the systems fixed, but one still fails: gdl-demos.
http://cl-test-grid.appspot.com/blob?key=941904
*By genworks on 2013-01-13 17:13:58 UTC*
Hi Anton,
Thank you for checking back.
Yep, indeed that locales.lisp is still in UTF-8 and is full of Chinese
characters. I will decide whether to go ahead and make the gdl-demos.asd
system be in UTF-8, or weed that file out of the system and just manage it
internally. If January Quicklisp release is this weekend, then I guess I'm
too late already. Otherwise I will target next weekend.
Best Regards,
Dave
On Sun, Jan 13, 2013 at 12:00 PM, Anton Vodonosov
<notifications@github.com>wrote:
> Most of the systems fixed, but one still fails: gdl-demos.
> http://cl-test-grid.appspot.com/blob?key=941904
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/41#issuecomment-12196322>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699https://gitlab.common-lisp.net/gendl/gendl/-/issues/125:ajax-submit-on-change? for form-controls always results in innerHTML refresh...2015-03-31T02:17:17ZDave Cooper:ajax-submit-on-change? for form-controls always results in innerHTML refresh -- is it needed?*Created by: genworks*
As it is currently, if you have a sheet-section with a form-control (a type of base-form-control from gwl/form-elements/source/primitives.lisp), and specify :ajax-submit-on-change? t, this will _always_ result i...*Created by: genworks*
As it is currently, if you have a sheet-section with a form-control (a type of base-form-control from gwl/form-elements/source/primitives.lisp), and specify :ajax-submit-on-change? t, this will _always_ result in the inner-html being "dirty" (i.e. :unbound) after the submission, therefore the innerHTML for the sheet-section will be refreshed via Ajax. In case that the form-control itself is the _only_ thing which was modified as a result of the submission, it might not be strictly necessary to refresh the HTML -- after all, the browser already has the correct state.
It has been reported by Reinier van Dijk that this over-zealous updating of the inner-html for the sheet-section sometimes "messes up the UI." On the other hand, allowing the inner-html to update does guarantee that the View (i.e. the content of the web page) will exactly match the Model (i.e. the sheet-section and form-control objects in Gendl). In other words, updating the inner-html acts to confirm for the user that the intended values from the View (browser) were indeed passed successfully into the server (the Model), through the Controller (i.e. the gdlAjax logic).
A self-contained example of how the UI can be "messed up" by the refresh of the inner-html of the sheet-section containing the form-control in question will be of great assistance in determining whether this is behavior which should be changed. In theory, it would be possible to detect when the form-control value is indeed the _only_ thing affected by the Ajax submission, and in that case to suppress the refreshing of the inner-html.
**Imported comments:**
*By genworks on 2013-01-12 22:57:53 UTC*
@reiniervandijk you may be interested in following this Issue.