Re: [qlist] [q-lang-users] CVS issues/Q 7.1

[Andrew B. <and...@ya...>]

Hi, Albert.

I tried a while ago to port Q to 64 bit, using a little bit of spare  
time at work, where I have an AMD 64 bit machine running Ubuntu  
Linux.  Since then I have become busy enough that I cannot devote  
enough time to do porting/development, but I could still do some  
testing.

Also, at home I use a Macintosh with OS X.  It is an Intel iMac.  I  
know that the Core Duo chip supports 64 bits, but I don't know if OS  
X supports 64 bits on it.  I also recall reading that the app  
framework is all 32 bits still, so OS X 64 bit processes cannot do  
much more than write to standard out.  If I recall, Apple decided  
that 64 bitness is mostly advantageous for scientific or server  
workloads, which do not need a shiny UI.

How much OS X support do you foresee?  On the low end of the effort  
scale would be just a basic command line, probably a few hours worth  
of effort.  At the other would be an Objective-C bridge with access  
to Cocoa, but I have not done that kind of port before, so I could  
only guess at the time required.  Lots of other projects do that kind  
of bridge, though, so I would imagine it to be in the range of a week  
or three of development time.

-andrew

On May 9, 2006, at 3:39 PM, Albert Graef wrote:

> Hi,
>
> not much traffic here for a while, so I thought a quick update was  
> in order. ;-)
>
> As some of you may have noticed already, anonymous cvs is currently  
> lagging behind developer cvs quite a lot (8 weeks!), apparently  
> because sf.net is currently deploying new cvs servers. There seem  
> to be some serious issues with the new servers, though (in fact,  
> currently even developer cvs doesn't work any more for me and lots  
> of other sf-hosted projects). That's unfortunate because Q 7.1 is  
> almost ready in cvs. :(
>
> I filed support requests on these issues but didn't receive a reply  
> yet (and if I see the number of cvs support requests piling up, I  
> doubt that I get a reply very soon), so I don't know when this mess  
> will be fixed.
>
> FYI, a quick summary of the new features in Q 7.1 is attached to  
> this post. The most important changes are in the warning messages  
> of the compiler and the handling of enumerations, streams and list  
> comprehensions, and there is still one more experimental new  
> feature on my TODO list for this release, which should further  
> improve the handling of lazy data structures.
>
> If anyone is interested in trying out the new release before I do  
> the final touches, I can upload an up-to-date tarball as a release  
> candidate.
>
> The road ahead: For Q 7.2, I'd like to work on the 64 bit support  
> and renew the support for OS X. Please let me know if you're  
> willing to help with that. (Currently I only have access to Intel  
> 64 bit machines, so any beta testers with other setups like AMD64,  
> G5 etc. are welcome...)
>
> Cheers,
> Albert
>
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
> * 7.1	(Unreleased, work in progress.)
>
> This release sports the following experimental new features:
>
> - Sentinel expressions: Clib now provides these as a special kind of
>   references to expressions whose evaluation is deferred until the  
> sentinel is
>   garbage-collected. Sentinels are a means to implement ordinary Q  
> data
>   structures which perform automatic cleanup in the same fashion as  
> some
>   built-in and external data types.
>
> - Improved warning messages: Undeclared variable symbols are not  
> reported with
>   -w anymore (these messages are often a nuisance if you use lambda  
> a lot),
>   and function symbols will only be reported as undeclared at the  
> end of a
>   source file, if they are neither imported nor declared _anywhere_  
> in the
>   file (where appearances of a function symbol on the left-hand  
> side of
>   equations and variable definitions count as implicit  
> declarations). If you
>   want to play it *really* safe, there is a new warning level -w2  
> a.k.a.
>   --pedantic which warns about *all* function and variable symbols  
> which are
>   used without a prior *explicit* declaration (i.e., when using  
> that option
>   you really have to declare each and every symbol explicitly, to  
> make the
>   compiler happy).
>
> - New builtins and standard library functions: The `+' and `-'  
> operators can
>   now be used to perform simple arithmetics on enumeration types.  
> If X is an
>   enumeration type member then X+N and X-N yields the Nth successor  
> and
>   predecessor of X, respectively, and if X and Y are members of the  
> same
>   enumeration type then X-Y yields the integer N s.t. X=Y+N.  
> Moreover, typec.q
>   offers a new typechecking predicate for enumeration type members  
> (isenum),
>   stream.q has a few new stream generation functions (repeat,  
> repeatn, cycle),
>   and `cat' and `tuple' now work with streams, too.
>
> - Syntactic sugar for streams and comprehensions: Streams can now  
> be written
>   in the same kind of notation as lists, but using curly braces  
> instead of
>   brackets, as in `{1,2,3}' or `{X|Xs}'. The new notation is  
> translated to an
>   appropriate application involving the stream constructors `bin'  
> and `nil'
>   (which are now predefined as builtins) by the parser, and is also  
> used when
>   an expression is printed. Moreover, the parser recognizes the  
> notations
>   `{1..10}' and `{1..}' for finite and infinite stream  
> enumerations, and
>   there's also new syntactic sugar for list and stream  
> comprehensions. E.g.,
>   you can now write `[2*X^2 : X in Xs, even X]' as a shorthand for  
> `listof
>   (2*X^2) (X in Xs, even X)'. Stream comprehensions (streamof) work  
> the same,
>   using curly braces instead of the brackets.
>
> - Other language extensions: There's an alternative syntax `type X  
> == Y' to
>   declare type aliases and the `var' keyword can now be used in  
> front of a
>   variable symbol on the right-hand side of an equation or variable  
> definition
>   to escape free variable symbols and declare them on the fly.
>
> Besides this, a rather annoying bug in the pattern matcher has been  
> fixed. As
> usual, you should check out the ChangeLog file and the language  
> manual for all
> the gory details.