duro-devel — Development

[Duro-devel] Support for PostgeSQL as a backend for DuroDBMS

[Rene H. <reh...@t-...>]

Hi,

I am currently adding support for using PostgeSQL as a storage engine 
for DuroDBMS as an alternative to Berkeley DB.

I also intend switching to the LGPL license. This will not have a big 
effect as long as Berkeley DB is required to build DuroDBMS. In a future 
version (probably 1.4) it will be possible to build DuroDBMS with 
PostgreSQL only.

--
René Hartmann
DuroDBMS implementer and maintainer

[Duro-devel] Interpreter header files

[Rene H. <reh...@t-...>]

Dear members of the Duro development mailing list,

I noticed after the 0.25 release that the header files dli/iinterp.h and 
dli/interp_eval.h do not get installed and are not part of the binary 
Windows distribution.

Since the issue is hardly worth a new release, I simply recommend to 
copy these file from the source tree to /usr/durodbms.0.25/include or 
the equivalent directory if you want to access the interpreter from C.

Regards,

René Hartmann

Re: [Duro-devel] binding D to other languages

[Rene H. <reh...@t-...>]

Tcl was designed from the beginning to be extensible. So although I 
never wrote an extension for Python, Perl, PHP or Ruby I think it's 
easier to write a D extension for Tcl than for other languages. As in D, 
there are no pointers or references in Tcl, only values and variables. 
So there is some conceptual similarity (although D and Tcl are very 
different in other respects).

Actually, Duro started as a C library. The Tutorial D interpreter came 
later. But a true D requires a separate language. The problem is that 
for many people 'relational == SQL'. It's an uphill battle because SQL 
dominates the DBMS market so much that there is not much room for a 
relational alternative.

I'm thinking about a PHP interface so it will be possible to write PHP 
web applications using Duro. But from what I read about extending PHP I 
would have to make the interpreter thread-safe first.

Am 05.03.2012 04:17, schrieb Practical Dee:
> I see you have found a way to make "D" useful in TCL. I'm not an expert on
> TCL, but I'm wondering if it is possible to bind "D" to other languages in
> addition to TCL.
>
> Have you made what is known as a "domain specific language" inside TCL? Is
> that how your TCL table system works, kind of a mini language inside TCL?
>
> Is TCL unique, in that you can modify it unlike other languages, enough to
> host a table oriented programming language inside it?
>
> In languages like C or Java or Delphi, it is hard to create small languages
> inside itself since the language is more fixed and permanent.  Is TCL one
> of those tools that you can modify so that the language can be extended? Is
> it in a way like lisp (since in lisp you can modify itself)?
>
> If you wanted to add "D" functionality to PHP or to delphi or to perl, I
> think it would it be much harder than TCL?  In Ruby they have some ability
> to make domain specific languages too - so I guess ruby would be easier to
> bind to "D", but I'm not a ruby expert either.
>
> Problem I see with Tutorial D and the Third Manifesto is that it doesn't
> make use of existing code.. it's a new language, and it will not catch on
> because people are going to just continue using what they already have:
> java, perl, ruby, C, C++, delphi, PHP, etc.
>
> pw. It is sad that projects like Duro and Rel (dbappbuilder) are not very
> popular - the industry completely ignores relational model and continues
> with SQL. No one cares. Complete apathy toward proper database tools.
>
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> Duro-devel mailing list
> Dur...@li...
> https://lists.sourceforge.net/lists/listinfo/duro-devel

[Duro-devel] binding D to other languages

[Practical D. <pra...@gm...>]

I see you have found a way to make "D" useful in TCL. I'm not an expert on
TCL, but I'm wondering if it is possible to bind "D" to other languages in
addition to TCL.

Have you made what is known as a "domain specific language" inside TCL? Is
that how your TCL table system works, kind of a mini language inside TCL?

Is TCL unique, in that you can modify it unlike other languages, enough to
host a table oriented programming language inside it?

In languages like C or Java or Delphi, it is hard to create small languages
inside itself since the language is more fixed and permanent.  Is TCL one
of those tools that you can modify so that the language can be extended? Is
it in a way like lisp (since in lisp you can modify itself)?

If you wanted to add "D" functionality to PHP or to delphi or to perl, I
think it would it be much harder than TCL?  In Ruby they have some ability
to make domain specific languages too - so I guess ruby would be easier to
bind to "D", but I'm not a ruby expert either.

Problem I see with Tutorial D and the Third Manifesto is that it doesn't
make use of existing code.. it's a new language, and it will not catch on
because people are going to just continue using what they already have:
java, perl, ruby, C, C++, delphi, PHP, etc.

pw. It is sad that projects like Duro and Rel (dbappbuilder) are not very
popular - the industry completely ignores relational model and continues
with SQL. No one cares. Complete apathy toward proper database tools.

Re: [Duro-devel] operator not found error?

[Rene H. <reh...@t-...>]

What version of Duro are you using? Do you use Duro 0.14 or the lastest 
version from the CVS repository? With Duro 0.14 you need a running 
transaction to invoke a user-defined operator. So a "begin tx;" before 
the "call inc(i);" should do it.

Duro 0.15 is going to be released soon. In this version, your code 
should work.

René Hartmann

Am 05.03.2012 01:08, schrieb Practical Dee:
> I try to create an operator like below and durodt tells me operator not
> found. Why would this be?
>
> D>  operator inc(i integer) updates {i};
> D>  i:=i+1;
> D>  end operator;
> Operator INC created.
> D>  var i integer;
> D>  i:=5;
> 1 element affected.
> D>  call inc(i);
> OPERATOR_NOT_FOUND_ERROR: INC
> D>  call inc;
> SYNTAX_ERROR: syntax error, unexpected ';', expecting '('
>
> p.s. The last error indicates that duro somehow knows about inc() because
> it detects the syntax error if inc being called improperly..
>
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> Duro-devel mailing list
> Dur...@li...
> https://lists.sourceforge.net/lists/listinfo/duro-devel

[Duro-devel] operator not found error?

[Practical D. <pra...@gm...>]

I try to create an operator like below and durodt tells me operator not
found. Why would this be?

D> operator inc(i integer) updates {i};
D> i:=i+1;
D> end operator;
Operator INC created.
D> var i integer;
D> i:=5;
1 element affected.
D> call inc(i);
OPERATOR_NOT_FOUND_ERROR: INC
D> call inc;
SYNTAX_ERROR: syntax error, unexpected ';', expecting '('

p.s. The last error indicates that duro somehow knows about inc() because
it detects the syntax error if inc being called improperly..

[Duro-devel] Replacing GNU Autotools by SCons

[Rene H. <reh...@t-...>]

Hello,

I am planning to replace GNU Autotools (Autoconf/Automake/Make) by
SCons (see www.scons.org).

The greatest benefit of this is that SCons works under (native) MS Windows.
Apart from that, it is simpler to use (at least I have reasons to assume
that).

So if It don't encounter unexpected problems with SCons, the next
release of Duro will use SCons fo building the software.

=2D-
Ren=E9 Hartmann

[Duro-devel] Plannend API changes

[Rene H. <reh...@t-...>]

Hello,

I'm considering major changes to the Duro API, which, as I hope, will
somewhat reduce the complexity of both the interface and the implementation.

The main idea is to do away with RDB_table and to use RDB_object for tables
instead. This also removes the calls which convert beween the two, which are
needed e.g. when setting relation-valued tuple attributes.

I also want to change the implementation of virtual tables so that they are
no longer represented by trees of tables, but refer to RDB_expressions.
This means that the calls RDB_join(), RDB_union(), etc. are no longer
supported; instead, a RDB_expression is created (using RDB_ro_op() and rela=
ted=20
calls) and this RDB_expression is converted to a RDB_object which respresen=
ts
the virtual table.

This will reduce the number of calls in the API and emphasize the point that
virtual tables are expressions; it also means there will be only one kind of
tree the library has to manage.

It may turn out that these changes don't work as expected because I
overlooked some of their implications. In any case, I want to inform
you of the changes I'm considering. I don't think there is much code out th=
ere
which gets broken by the changes; should I be wrong on this, please inform =
me.

=2D-
Ren=E9 Hartmann

[Duro-devel] Call For Papers: 13th Annual Tcl/Tk Conference, Oct. 9-13, 2006

[<aku...@sh...>]

Tcl/Tk
 - radically simple
 - radically flexible
 - radically powerful

Announcing the 13th Annual Tcl/Tk Conference

October 9-13, 2006
Naperville, Illinois USA

Learn from the experts, share your experience - the annual Tcl/Tk
conference is your opportunity to engage with the Tcl/Tk core team and
your fellow peers.

The conference program will include:
  * Presentations and tutorials
  * The (Active)State of Tcl talk by Tcl/Tk release manager Jeff Hobbs
  * Birds of a Feather (BOF) sessions
  * Invited key-note talks
  * Discussion forums with the Tcl/Tk core team

Call For Papers

You are invited and indeed encouraged to submit proposals for
presentations and tutorials. The conference schedule will consist of two
days of tutorials (Monday - Tuesday) and 3 days for the main
conference (Wednesday - Friday).

The conference provides you an opportunity to report on original
research and applications of Tcl/Tk and related technology. The
audience will consist of practitioners and researchers who are
intermediate or experienced users of Tcl/Tk.  For this reason, reports
on experiences and applications should draw out lessons for other
Tcl/Tk developers.

Topics will include, but are not limited to:

  * Application of Tcl/Tk in industries as diverse as engineering,
      industrial controls, broadcasting, financial services,
      medical and electronic design
  * Networking with Tcl/Tk, including distributed applications and network
      management
  * New widgets and techniques for GUI design with Tk
  * Simulation and application steering with Tcl/Tk
  * Tcl/Tk on handheld and embedded devices
  * New Tcl extensions and add-ons, including Tcllib and Tklib
  * Tcl/Tk centric operating environments

Submission Guidelines

If you are interested in submitting a paper you should send an
abstract of about 100 words and a summary of maximum two pages. Omit
extraneous or redundant information. Length is not a direct factor in
judging the quality of the submission.

If submitting a tutorial proposal you should send an outline of the
tutorial and a brief biography, and clearly indicate whether the
tutorial is of half-day or full-day duration.

Send submissions as plain text to <tc...@tc...> no later than May
31, 2006.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

The program committee will review and evaluate papers according to
the following criteria:
  * Quantity and quality of novel content
  * Relevance and interest to the Tcl/Tk community
  * Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application.  Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread.  All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

Registration Information

More information on the conference will be available in Spring 2006 at
the conference web site (http://www.tcl.tk/community/tcl2006/) and
published on various Tcl/Tk related information channels.

To keep in touch with conference announcements and Tcl events in
general, subscribe to the tcl-announce list at:

   http://listserv.activestate.com/mailman/mysubs?show=announce

by entering your email and selecting Tcl-announce.

Conference Committee

Cyndy Lilagan     Eolas Technologies              Facilities Coordination
Clif Flynt        Noumena Corp                    General Chair
Steve Redler IV   SR Technology                   Program Chair
Steve Landers     Digital Smarties                Program Co-chair
Kevin Kenny       GE Global Research Center
Jeffrey Hobbs     ActiveState
Andreas Kupries   ActiveState
Mike Doyle        Eolas Technologies
Ron Fox           NSCL Michigan State University
Donal Fellows     University of Manchester
Gerald Lester     HMS Software
Larry Virden      Tcl FAQ Maintainer

Contact Information

tc...@tc...
http://www.tcl.tk/community/tcl2006/


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[Duro-devel] Possible Duro API changes

[Rene H. <reh...@t-...>]

=46or the next release of Duro (which will feature declarative integrity
and multiple assignment and thus be a big step forward towards full D
compliance) I am onsidering some changes to the API.

Since I don't know how much code already exists which was written
for the Duro API, I hereby would like to ask the "Duro Community" for=20
comments.

1. Support for exceptions

Currenty, both Duro functions and user-defined operators return error
information through a numerical error code, which is not sufficient
for all cases. For example, if a function fails for a constraint violation,
there should be some way to find out about the constraint that has been
violated. Also, user-defined operators may need to return more error
information than just an error code.

To solve these issues in a uniform way, I am considering the use of
exceptions. In the context of C, which does not provide exception
handling, this means that, in the case of failure, a function or operator
may return an exception value, which can carry any kind of error
information.

Even if I see no problem in allowing any type used for an exception,
user-defined types seem to be a good choice for exceptions.
Because they, unlike non-scalar types, are named, different types
of errors can be distinguished simply by the exception type name.
An exception type usually would have only one possible representation,
and the components of this representation would constitute the error
information.

=46or the mechanism used to return the exception value to the caller, I
am considering two ways:
(1) Using an exception argument (of type RDB_object *) which contains
the exception value if the function returns with an error.
(2) Attaching the exception value to the transaction which was passed
to the function in question.

(1) is the cleaner way, but means that all functions which can return an
exception get an additional argument.
(2) is more backwards-compatible, as it only requires every function
that can return an exception value to have a transaction argument.

I am not sure yet which is the better way here. I like the idea of rewriting
the API to get a completely exception-based API instead a mix of the
exception-based and the old return-value-based approach.
But this is lots of work and I don't know how much code is "out there"
(if any) that has been written for the current API.

2. Releasing resources on transaction rollback

This is much more vague than 1. In the discussion raised
by Raymond Chen's famous web article "Cleaner, more elegant,
and harder to recognize"
(http://blogs.msdn.com/oldnewthing/archive/2004/4/22.aspx),
some people mentioned transactions as a way to prevent resource
leaks.

This lead me to the idea to make Duro free resources on transaction
rollback. For example, if you create a complex virtual table using
the Duro API, you have to check for an error at each step and
to free all virtual tables you created so far, which is quite tedious
and error-prone. This problem might be solved if, say, all unnamed
tables and all expression which are not part of a virtual table
are released at transaction rollback, because then, if an error
occurs, you simply do a rollback and all partial virtual tables
are dropped automatically. But I'm not quite sure if this
doesn't raise other problems, and it may lead to excessive use
of subtransactions, which may be a performance problem.

Comments are appreciated.

=2D-
Ren=E9 Hartmann

[Duro-devel] Tcl/Tk 2005 Conference - Schedules available now, Registration is open

[<aku...@sh...>]

Tcl/Tk 2005 Conference Schedule & Registration
==============================================

The 12th Tcl/Tk Conference Schedules are available.

The tutorials and paper presentation schedules have been 
finalized and are available at:

http://www.tcl.tk/community/tcl2005/tut2005.html
http://www.tcl.tk/community/tcl2005/schedule.html

The abstracts for the selected papers are available at:

http://www.tcl.tk/community/tcl2005/abstracts.html

The conference dinner will be on Wednesday evening.  
Blueteam will be providing a social hour with drinks
and munchies on Thursday evening.

Registration is open for tutorials and technical 
sessions at:

http://www.tcl.tk/community/tcl2005/reg.html


Program Committee:
==================
 Donal  Fellows       University of Manchester
 Clif   Flynt         Noumena Corp.
 Ron    Fox           NSCL Michigan State University
 Jeff   Hobbs         ActiveState Corp.
 Steve  Landers       Digital Smarties
 Gerald Lester        HMS Software
 Cyndy  Lilagan       Eolas Technologies Inc.
 Arjen  Markus        WL | Delft Hydraulics

--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[Duro-devel] Tcl/Tk 2005 Second Call for papers

[<aku...@sh...>]

Submission of Summaries

Tcl/Tk 2005 will be held in Portland, Oregon USA from October 24 -
October 28. The program committee asks all people using and developing
with Tcl/Tk and extensions to submit papers and proposals for
presentations at this conference. Past conferences have seen
submissions covering a wide variety of topics including and not
limited to:

    * Scientific and engineering applications
    * Industrial controls
    * Distributed applications and Network Managment
    * Object oriented extensions to Tcl/Tk
    * New widgets for Tk
    * Simulation and application steering with Tcl/Tk
    * Tcl/Tk-Centric operating environments
    * Tcl/Tk on small and embedded devices
    * Medical applications and visualization
    * Use of different programming paradigms in Tcl/Tk and proposals
      for new directions.
    * New areas of exploration for the Tcl/Tk language 

The submissions should consist of an abstract of about 100 words and a
summary of maximum two pages. Omit extraneous or redundant
information. Length is not a direct factor in judging the quality of
the submission.

Send submissions as plain text to <tcl2005 AT tcl.tk> no later than
July 1, 2005. Authors of accepted abstracts will have until September
15, 2005 to submit their final paper for the inclusion in the
conference proceedings. The proceedings will be made available on
CD-ROM, so extra materials like code samples are welcome.

The authors will have 20-25 minutes to present the paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

    * Quantity and quality of novel content
    * Relevance and interest to the Tcl/Tk community
    * Suitability of content for presentation at the conference 

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August, 2005. Specific instructions for reserving WIP and
BOF time slots will be provided in the registration information
available in June 2005.  Some WIP and BOF time slots will be held open
for on-site reservation, so we encourage all attendees with
interesting work in progress to consider presenting that work at the
conference.  Registration Information

More information on the conference will be available in April 2005 at
the conference Web site and published on various Tcl/Tk-related
information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list.

Conference Committee

Brian Griffin   	Mentor Graphics	      Facilities Coordination
Clif Flynt	   	Noumena Corp	      General Chair, Website Admin
Ron Fox     		NSCL MSU              Program Chair
Arjen Markus   		WL Delft Hydraulics	
Cyndy Lilagan   	Eolas Corp	
Gerald Lester   	HMS Software	
Donal Fellows   	University of Manchester	
Jeffrey Hobbs   	ActiveState Corp	
Steve Landers   	Digital Smarties	
Kevin Kenny   		GE Global Research Center	
Ken Jones   		Avia Training	
Sheila Miguez   	mVerify	
Larry Virden   		Tcl FAQ Maintainer	
Andreas Kupries 	ActiveState Corp	

Contact Information <tcl2005 AT tcl.tk>


--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

[Duro-devel] Tcl/Tk 2005 First Call for papers

[<aku...@sh...>]

Tcl/Tk 2005 First Call for papers.
===================================

Tcl/Tk 2005 will be held in Portland, Oregon USA in late October or
early November.  The program committee asks all people using and
developing with Tcl/Tk and extensions to submit papers and proposals
for presentations at this conference.

Past conferences have seen submissions covering a wide variety of
topics including and not limited to:

   * Scientific and engineering applications
   * Industrial controls
   * Distributed applications and Network Managment
   * Object oriented extensions to Tcl/Tk
   * New widgets for Tk
   * Simulation and application steering with Tcl/Tk
   * Tcl/Tk-Centric operating environments
   * Tcl/Tk on small and embedded devices
   * Medical applications and visualization


At this point we are requesting submissions of:

   * Abstracts of papers for oral presentation.
   * Proposals for short courses to be taught the day prior to the conference.
   * Proposals for other presentations/discussions.
   * Proposals to present tutorial sessions.

Please send abstracts and proposals to tcl2005 (at) nscl (dot) 
msu (dot) edu

Important target dates:
=======================
 July  1, 2005    - Abstracts and proposals due.
 July 31, 2005    - Notification to authors.
 Sep  15, 2005    - Author materials due.

The submissions should consist of an abstract of about 100 words and a
summary of maximum two pages.  Omit extraneous or redundant
information. Length is not a direct factor in judging the quality of
the submission.

The authors of oral presentations will have 20-25 minutes to present
the paper at the conference.

The program committee will review and evaluate papers according to the
following criteria:

   * Quantity and quality of novel content
   * Relevance and interest to the Tcl/Tk community
   * Suitability of content for presentation at the conference 

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreement forms will be returned
to the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.



Program Committee:
==================
 Donal  Fellows       University of Manchester
 Clif   Flynt         Noumena Corp.
 Ron    Fox           NSCL Michigan State University
 Jeff   Hobbs         ActiveState Corp.
 Steve  Landers       Digital Smarties
 Gerald Lester        HMS Software
 Cyndy  Lilagan       Eolas Technologies Inc.
 Arjen  Markus        WL | Delft Hydraulics

--
Sincerely,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: [Duro-devel] RPM spec file

[<reh...@t-...>]

Daniel Hanks wrote:
> Not sure if this will come through or not, but I've attached a spec file, which one can use to wrap the duro library into an rpm. Feel free to add it to the tarball, if you'd like.
>
> I'm also toying with the idea of building a Perl wrapper around the library. We'll see where that goes.
>

Great. But be aware that the API is not stable yet, so some calls will
change with the next release. I'm planning to release version 1.0 of the
spec with the next release of Duro.

--
Rene´

[Duro-devel] RPM spec file

[Daniel H. <ha...@ab...>]

Not sure if this will come through or not, but I've attached a spec file, which one can use to wrap the duro library into an rpm. Feel free to add it to the tarball, if you'd like.

I'm also toying with the idea of building a Perl wrapper around the library. We'll see where that goes.

-- Dan
========================================================================
   Daniel Hanks - Systems/Database Administrator
   About Inc., Web Services Division
========================================================================

[Duro-devel] TODO List

[<reh...@t-...>]

OK, here's my TODO list for Duro. It's rather long and contains both
things I want to add for the next version(s) and things which may take
quite a lot of time to be implemented.

- Normalize catalog table SYS_RO_OPS
- Change definition of selectors so that they are defined in the same way
  as other user-def operators
- User-defined types with internal tuple rep
- Make it possible to check the type of an expression before evaluation
- Change RDB_binary_get() so that it returns a pointer to the data,
  instead of copying it
- Implement RDB_project_tuple() and RDB_join_tuples().
- Add "subset of" operator
- Expression parser: tuple literals, tuple operations (project etc.),
  PREFIX, SUFFIX clauses of RENAME
- Expression parser: fix memory management (the parser currently leaks memory
  if a syntax error ocurs)
- Implement SAME_TYPE_AS
- Implement insert, update, and delete for all kinds of virtual tables
  (where possible)
- Support custom memory allocator
- Support user-provided logging function
- Function to get all DBs for a given DB environment
- Fix RDB_is_syserr() (currently implemented as a macro which uses its
  argument twice)
- Export/import utility
- GUI admin tool
- Make the library thread-safe
- Java interface
- Query optimizer
- Support indexes for non-key attributes
- Array-valued Attributes(?)
- Relation-valued attributes, GROUP und UNGROUP
- Array functions: implement RDB_array_set(), implement buffering of
  tuples (currently RDB_array_get() always accesses the underlying table)
- TCLOSE
- Better checking of function arguments
- More test scripts
- Tutorial
- Add option to let the system generate the setter methods of user-defined
  types, using getters and selector
- System-generated keys
- Rework key inference
- B-tree indexes
- Great divide
- "Alter table" function
- Add tracking of dependencies between tables and between tables and user-def types
  and operators
- Foreign keys / constraints
- Tutorial D interpreter/compiler
- SQL interface

--
Rene´ Hartmann

Re: [Duro-devel] Java interface

[Simon C. <sco...@us...>]

For sure .. A nice benefit of a Java interface would be the support for
scripting languages like Beanshell, Python, Javascript etc. that you get
through the Bean Scripting Framework. Together with Tcl it would make it
quite easy to experiment interactively with Duro.

Simon

On Fri, 12 Dec 2003 23:45:14 +0100 (CET), "Rene Hartmann"
<reh...@t-...> said:
> A Java interface for Duro would be a good thing, and I think
> it's not very hard to implement. There is the problem that,
> because Java is multithreaded, a library must be thread-safe
> when called from Java.
>=20
> Making Duro thread-safe should be not very difficult,
> but requires some work. Maybe a global lock can be an interim solution.
>=20
> Duro 0.7 will contain a Tcl interface; it will even be possible
> to write user-defined operators in Tcl (but not user-defined types,
> I will add this in a later version).
> In a similar way a Java interface could provide user-defined operators
> written in Java.
>=20
> --
> Rene=B4 Hartmann
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Duro-devel mailing list
> Dur...@li...
> https://lists.sourceforge.net/lists/listinfo/duro-devel
--=20
  Simon Collins
  sco...@fa...

[Duro-devel] Java interface

[<reh...@t-...>]

A Java interface for Duro would be a good thing, and I think
it's not very hard to implement. There is the problem that,
because Java is multithreaded, a library must be thread-safe
when called from Java.

Making Duro thread-safe should be not very difficult,
but requires some work. Maybe a global lock can be an interim solution.

Duro 0.7 will contain a Tcl interface; it will even be possible
to write user-defined operators in Tcl (but not user-defined types,
I will add this in a later version).
In a similar way a Java interface could provide user-defined operators
written in Java.

--
Rene´ Hartmann