Rolf Veen | 19 Sep 2011 17:43
Picon

Spec change (in level 2)

Hi, all. I was never happy with the level 2 grammar (the part that
allows cycles).
It was two complex from my point of view, and difficult to implement.
I've updated
the spec with a small change in that section, so that only one syntax for cycles
remains:

a
  b
c
  #{2

Here, 'c' links to the node 2 lines above. Since in the canonical form of OGDL
there are not more than one node on each line, the number is a coordinate in
the vertical direction and identifies uniquely a node. Negative numbers point
to nodes after the current node.

Kind regards
Rolf.

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Lluís Batlle i Rossell | 27 Jan 2007 17:02
Picon
Gravatar

Looking for a C++ implementation

Hi,

I see (in the repository) there isn't any C++ implementation of an OGDL
parser. I'd like to have one :) I like the Java approaches between the
parser and file reader objects.

What are the people here using OGDL for the most? Really like RPC, or
for storing data?

(Maybe I should get into ogdl-users or something like that :)
Attachment (smime.p7s): application/x-pkcs7-signature, 3311 bytes
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Ogdl-core mailing list
Ogdl-core <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ogdl-core
Lluís Batlle | 10 Jan 2007 10:18
Picon
Gravatar

J2me small update

Hi,

I'm just new in OGDL, but I find it's really great.

I started using OGDL in a J2ME application, and I found that there is
only a OgdlBinary parser there. I took the code for OgdlParser and
Characters from the "java" version, and got the text parser working in
CLDP.

Maybe someone wants to check those changes into svn...

(I've not really *strongly* tried the text parser - I only have a
simple OGDL text file in my JAR, and I can load the graph without any
problems)

Regards,
Lluís.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Rolf Veen | 14 Aug 2006 18:02

Subversion repository active

Hi, all. It's a long time, but I'm still here :-).

I've just set up the subversion repository for the
project, meaning that CVS is from now on deprecated.

New additions to the code are those related to the
binary version of OGDL and an OGDL/RF protocol
implementation on top of TCP. There are RFClient
and RFServer implementations for each language,
making possible to brigde language barriers with
very low overhead (compared to SOAP, for example).

There is also a Java Microedition version that
is able to load into a Java device and remotely
connect it to an OGDL/RF server to interchange
(binary) OGDL objects.

The java/ and j2me/ are Eclipse projects (the
second one needs EclipseME).

Cheers.
Rolf.

PS. Didge: your code is preserved as is, and
available in java-digde/.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
(Continue reading)

didge | 12 Jan 2006 00:18
Favicon

DIDGE_001 branch changes

I just completed checking in new changes to the DIDGE_001 branch.  I'm
currently working on a port to C# (almost complete) and I've been
simultaneously changing the Java version to make the two more consistent,
where possible.

Regards,

didge

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
didge | 5 Jan 2006 23:04
Favicon

New branch is ready

Folks,

I've just committed a number of new files to the project on a new branch
called DIDGE_001.  As stated previously, the purpose of this branch is to
avoid confusion with the current public release, especially since the new
files represent experimental thinking that the whole team may not want as a
whole.

My main goals with this branch were as follows:
1. Learn OGDL.
2. Create a pull parser that could reproduce the input stream exactly.
3. Provide a serializer for convenient generation of OGDL streams.
4. Clarify some of the ambiguities in the grammar. 
5. Experiment with a simpler package structure.

To access these files, I suggest that you create a new working directory and
then perform a fresh checkout using:
	cvs checkout -r DIDGE_001 java

I've organized the files in this branch as an OGDL Java SDK.  Included are
ant build scripts, examples, documentation, and of course the source.  After
you check it out, you can use Ant to build it by simply executing 'ant' in
the new working directory which will build everything including javadocs.

I did not attempt to bring forward everything that currently exists for Java
into this new branch.  Please don't be alarmed by this.  

What's New and Different

1. Package names.
(Continue reading)

didge | 28 Dec 2005 21:56
Favicon

Extraneous Commas and Parens

One of the things that I noticed is that the spec does not explicitly
prohibit the following ogdl:

 a()

and

 a,

While extraneous parens and commas could simply be ignored by the parser, I
would prefer to treat them as errors because they indicate possible errors
in the data that would be useful to capture in a data interchange as early
as possible.

My pull parser currently reports extraneous commas and parens as errors by
changing the grammar slightly:

[15] node ::= scalar space? (node|list|group)?

[16] list ::= ',' space? node

[17] group ::= '(' space? node space? ')'

[18] line(n) ::=
        space(n) node space? break  |
        space? comment? break |
        space(n) block

Essentially, this now says that commas must be followed by a scalar and
parens must contain a scalar.  This makes the following fundamentally
(Continue reading)

didge | 28 Dec 2005 21:51
Favicon

Pull parser update

I've mostly completed my second pull parser implementation for ogdl and am
preparing to commit it.  After conferring with Rolf, I plan to commit it and
its supporting files into a branch rather than commit it to MAIN in order to
reduce conflicts and confusion.  The branch name will be DIDGE_001.  I will
post when it is ready.

While still experimental, the implementation currently supports all of the
level 1 ogdl features (except meta information) and provides the tokens
necessary to support a roundtrip.

Regards,

didge

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
Rolf Veen | 19 Dec 2005 09:42

Binary OGDL spec

Hi, all.

I've uploaded a new spec of a binary version of
OGDL, and an associated 'Remote functions' spec.

The binary format is intended to be exchanged
between machines, as it allows to intermix normal
text nodes with images, etc.

The RF spec defines a way to expose functions as
remote services, by making the call and the response
be OGDL binary objects.

--
Rolf.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
didge | 16 Dec 2005 02:38
Favicon

Comment indicator and indentation

Rolf,

Just noticed you updated the definition of comments.  I was just about to
ask about that.  You must have been reading my mind!

Now, my next question: According to the grammar, it appears that spaces in
front of a comment may be significant and actually change the level of
indentation if there is not an intervening list or group:
[17] line(n) ::=
        space(n) (list|group)?  space? comment? break  |
        space(n) block

So in this example:

a    # level 0
 b   # level 1
  c  # level 2
   d # level 3
 # what is the indentation level after this comment?
   e  # level ?

is e's level 2 or 3?  By my reading of the grammar above, e should be at
level 2 because the spaces before the comment will taken as space(n) and set
the level to 1.

If this is true, doesn't it violate a general principle in programming
languages that comments in code don't have side effects on the code before
or after them? (Assuming you are not commenting out code of course!).

If this is false, should the grammar reflect this?  Maybe something like:
(Continue reading)

didge | 13 Dec 2005 20:17
Favicon

OgdlPullParser interface

/*
Here is the interface for my first pass OGDL pull parser implementation.
*/

/*
 * Copyright (c) 2005 FoundryLogic, LLC. All Rights Reserved.
 */
package org.ogdl.parser.ogdl;

import java.io.*;

public interface OgdlPullParser {
    // Basic token types
    int FORMATTING = 0;
    int START = 1;
    int END = 2;
    int START_META = 3;
    int END_META = 4;
    int START_GRAPH = 5;
    int END_GRAPH = 6;
    int ANCHOR = 7;
    int REF = 8;
    int PATH = 9;

    // Advanced token types to support formatting.
    // Note that by masking the high 24 bits, you get the basic token above
    int BREAK = 0x0100;
    int COMMA = END_GRAPH + 0x0200;
    int IGNORABLE_WHITESPACE = 0x0300;
    int START_GROUP = 0x0400;
(Continue reading)


Gmane