headers
Nico de Jager | 1 Aug 2008 09:00

64-bit Professional versions?


Hi

Will there be 64-bit Professional versions of LispWorks at some stage?

I would like to upgrade at least one of my licenses to a 64-bit version when my maintenance contracts expire,
but don't need the extra stuff in the Enterprise Edition at this stage.

Thanks.
Nico

PS. This should probably go to lisp-sales <at> lispworks.com but I think there are other users out there that
would like this question answered.
Permalink | Reply | 14 comments |
headers
Edi Weitz | 1 Aug 2008 12:54
Picon
Favicon

Re: LispWorks and code compatibility


On Thu, 31 Jul 2008 12:19:24 +0200, Espen Vestre <ev <at> netfonds.no> wrote:

> It's generally very compatible. Even GUI code (written with CAPI)
> needs very few #+-es to work. I grepped through 37k lines of my GUI
> code, and the only thing I found was some fine-tuning of sizes of
> fonts and gui elements, and different path name defaults for
> different OSes.

I can confirm that.  As long as you don't use OS-specific things like,
say, MDI interfaces on Windows, the only area where you /could/ run
into compatibility problems with GUI apps is the relation between
threads and GUI elements (specifically editor panes) on OS X vs. other
platforms.  If you're aware of this and code "defensively", so to say,
you should be fine.
Permalink | Reply | 4 comments |
headers
Espen Vestre | 1 Aug 2008 13:01
Picon
Favicon

Re: LispWorks and code compatibility


Edi Weitz <edi <at> agharta.de> writes:

> I can confirm that.  As long as you don't use OS-specific things like,
> say, MDI interfaces on Windows, the only area where you /could/ run
> into compatibility problems with GUI apps is the relation between
> threads and GUI elements (specifically editor panes) on OS X vs. other
> platforms.  If you're aware of this and code "defensively", so to say,
> you should be fine.

Very good point, Edi. Shame on me for forgetting to mention that.
The limitation on OS X is that all GUI operations run in a single thread,
which means that "execute-with-interface" will not run in a different
thread if it's called from one interface with a different interface
as a parameter.

To the LispWorks guys: Any plans on changing that in a future release?
It has given me a few headaches every now and then.
--

-- 
  (espen)
Permalink | Reply | 3 comments |
headers
Chun Tian (binghe | 1 Aug 2008 14:30
Picon

Re: LispWorks and code compatibility


>
>> I can confirm that.  As long as you don't use OS-specific things  
>> like,
>> say, MDI interfaces on Windows, the only area where you /could/ run
>> into compatibility problems with GUI apps is the relation between
>> threads and GUI elements (specifically editor panes) on OS X vs.  
>> other
>> platforms.  If you're aware of this and code "defensively", so to  
>> say,
>> you should be fine.
>
> Very good point, Edi. Shame on me for forgetting to mention that.
> The limitation on OS X is that all GUI operations run in a single  
> thread,
> which means that "execute-with-interface" will not run in a different
> thread if it's called from one interface with a different interface
> as a parameter.
>
> To the LispWorks guys: Any plans on changing that in a future release?
> It has given me a few headaches every now and then.

This should be a limitation/feature of the Mac OS X platform itself. I  
think you could try to ask Apple guys instead:)

--binghe
Permalink | Reply | 2 comments |
headers
davef | 1 Aug 2008 18:36
Favicon

Re: 64-bit Professional versions?


 > Hi
 > 
 > Will there be 64-bit Professional versions of LispWorks at some
 > stage?

There's no plan for that.

 > I would like to upgrade at least one of my licenses to a 64-bit
 > version when my maintenance contracts expire, but don't need the
 > extra stuff in the Enterprise Edition at this stage.

Our position is that 64-bit is an Enterprise feature.

Upgrade prices are shown at http://www.lispworks.com/buy/prices.html

 > Thanks.
 > Nico
 > 
 > PS. This should probably go to lisp-sales <at> lispworks.com but I think
 > there are other users out there that would like this question
 > answered.

--

-- 
Dave Fox
LispWorks Ltd
http://www.lispworks.com/
Permalink | Reply | 0 comments |
headers
John DeSoi | 1 Aug 2008 19:11
Favicon

Re: LispWorks and code compatibility


On Aug 1, 2008, at 8:30 AM, Chun Tian (binghe) wrote:

>> To the LispWorks guys: Any plans on changing that in a future  
>> release?
>> It has given me a few headaches every now and then.
>
> This should be a limitation/feature of the Mac OS X platform itself.  
> I think you could try to ask Apple guys instead:)

I use other Mac development tools that have great debuggers -- you can  
trace through any code including user interface code. So it is  
possible somehow.

For me this is the biggest limitation of LispWorks on the Mac. I  
constantly want to set a breakpoint in an interface callback to step  
through the code. Currently, there no way to do this with LispWorks Mac.

John

John DeSoi, Ph.D.
Permalink | Reply | 1 comment |
headers
Raffael Cavallaro | 1 Aug 2008 20:08
Picon

Re: LispWorks and code compatibility


On Aug 1, 2008, at 1:11 PM, John DeSoi wrote:

> I use other Mac development tools that have great debuggers -- you  
> can trace through any code including user interface code. So it is  
> possible somehow.
>
> For me this is the biggest limitation of LispWorks on the Mac. I  
> constantly want to set a breakpoint in an interface callback to step  
> through the code. Currently, there no way to do this with LispWorks  
> Mac.

To be more precise than Chun Tuan was, it is possible to run GUI  
elements in separate threads (I do so in Clozure CL for example).  
However, the AppKit itself is not thread safe so any call in any  
thread that causes a GUI element to be modified (i.e., redrawn) needs  
to happen on the main thread. The AppKit provides  
performSelector:onMainThread:withObject:waitUntilDone: (and others)  
for this purpose.

So yes, you can have GUI code on more than one thread, but then you  
have to be careful to always call visible GUI element modifications on  
the main thread. For example, you can allocate and initialize GUI  
elements on a separate thread, but when you show them, you must do it  
on the main thread.

regards,

Ralph
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rommel Martinez | 5 Aug 2008 05:27
Picon

Listener font


I'm using LWF and I want to know how to change the Listener font.
Mine is always displaying Lucida Typewriter. I was able to change
all fonts, except for the listener.

Any hints? :-)

--

-- 
Rommel M. Martinez
ebzzry <at> gmail.com
http://www.bespin.org/~ebzzry
Permalink | Reply | 2 comments |
headers
Nick Levine | 5 Aug 2008 08:43
Favicon
Gravatar

Re: Listener font


   I'm using LWF and I want to know how to change the Listener font.
   Mine is always displaying Lucida Typewriter. I was able to change
   all fonts, except for the listener.

Make either an editor or the listener the active window and then go to
the "preferences" dialog. On the "font" tab click "all lispworks
windows", select a font and hit OK.

-nick
Permalink | Reply | 1 comment |
headers
Nico de Jager | 5 Aug 2008 10:25

Re: Listener font


Nick Levine <ndl <at> ravenbrook.com> writes:

>    I'm using LWF and I want to know how to change the Listener font.
>    Mine is always displaying Lucida Typewriter. I was able to change
>    all fonts, except for the listener.
>
> Make either an editor or the listener the active window and then go to
> the "preferences" dialog. On the "font" tab click "all lispworks
> windows", select a font and hit OK.
>
> -nick

In addition, for more customization than just fonts through the GUI, check out the X11 resource file(s)
(i.e. ~/Lispworks or the examples in /usr/local/lib/LispWorks/lib/5-1-0-0/app-defaults/).

Nico
Permalink | Reply | 0 comments |

Gmane