eclipse-archived / ceylon-sdk Goto Github PK

Currently we do not have any way to express interval between two dates. Operations are useful in everyday life that we can express through this feature.

Currently i was thinking in somthing similar to:

shared interface Interval<Kind> satisfies Ranged<Kind, [Kind*]> 
                                given Kind satisfies Comparable<Kind> & Ordinal<Kind> {

    shared formal Kind start;
    shared formal Kind end;
    shared formal Duration duration;
    shared formal Period period;

    "inclusive..."
    shared formal Interval<Kind>? overlap( Interval<Kind> other );

    "exclusive..."
    shared formal Interval<Kind>? gap( Interval<Kind> other );

   ... more usefull methods

}

but in this case i need to have Instant, Date, DateTime and Time as Ordinal, actually we plan to have it as:

Instant: sucessor/predecessor by millis
DateTime: ... by millis
Time: ... by millis
Date: ... by day

and i personally dont think its usefull for Interval because do span(x,2) in millis for DateTime isnt the best option.

So, should i discard the satisfies Ranged and only use some methods like:

   actualDate.to( anotherDate ).byDate();
   or 
   actualDate.to( anotherDate ).sequenceBy( days ); //we actually have objects: years, months, days, hours, minutes, seconds, millis...

So, is there any way to make Interval satisfies Ranged with some easy configuration of sucessor/predecessor? it can be used also for make a sequence field in interval to return all Kinds of the Interval.

and of course any new option would be welcome

I'm trying a GET on a php script that returns UTF-8 json but the response.contents contains invalid chars

url: http://www.somatik.be/temp/me.php

Test code below:

shared void run() {
    value uri = parseURI("http://www.somatik.be/temp/me.php");
    value response = uri.get().execute();
    print(response.charset);
    String json = response.contents;
    value jsonObject = parse(json);
    print(jsonObject.pretty);
    print(jsonObject.getString("fullname"));
}

This prints in the eclipse console

UTF-8
{
 "fullname": "Fr?n?is De Brabandere"
}
Fr?n?is De Brabandere

Setting the source file encoding to UTF-8 instead of US-ASCII fixes the issue in eclipse (edit - set encoding)

UTF-8
{
 "fullname": "Fränçis De Brabandere"
}
Fränçis De Brabandere

this is the console curl output

curl http://www.somatik.be/temp/me.php
{"fullname": "Fränçis De Brabandere"}

curl --head http://www.somatik.be/temp/me.php
HTTP/1.1 200 OK
Date: Mon, 12 Nov 2012 21:15:02 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_jk/1.2.35
X-Powered-By: PHP/5.3.17
Content-Type: application/json; charset=UTF-8

the console ceylon run always prints wrong characters:

ceylon run demoBof/1.0.0
UTF-8
{
 "fullname": "Fr?n?is De Brabandere"
}
Fr?n?is De Brabandere

The build.xml for the sdk is made more complex than necessary because we need the version number of the module to be the same as the version for its test module and this number needs to be known to ant (via the build.properties) so it can run the test module.

If we had an ant task that could set a property to the version number in the module descriptor, this would help, because then we wouldn't need to keep the version number in the build.properties in sync.

A couple of problems with the build script:

1. We need the ability to publish to the local repo for testing.
2. There is hardcoded /home/tom/ceylon that needs to be configable.

Fix Whole and Decimal now that ** is defined in terms of Exponentiable (ceylon/ceylon-spec#157)

Hi Gavin, not sure the best place for inane amateur comments such as this but... The file API looks very clean and I can't wait to start using this in production. At first glance I wondered what was this Nil type and wondered if I had missed something from the ceylon docs as it seems such a generic name used for other purposes in other languages. I then saw that it is paired with ExistingResource to make creating missing resources easy.

I thought that names Missing and Existing (c.f. Nil and ExistingResource) might make your examples easier to read:

if (is Missing loc = filePath.resource)
if (is Existing loc = filePath.resource)

I find it highly unintuitive that things like URIs and Paths are mutable in ceylon.net, and whenever you run into APIs like this it always leaves you wondering things like:

what happens if I mutate a URI of an already created Request?

The answer to questions like these are never obvious to a client of an API!

As it turns out, this changes the Request to point to a different URI, which raises the question of why in hell is Request an object and not a function if it doesn't seem to have any actual meaningful state! I mean what is its identity? What is it a request for?! At the moment its identity is that it's a Request for whatever a certain object instance—as determined by ===—of URI happens to be pointing to at a certain moment in time! That is to say, it has no really welldefined identity and doesn't deserve its objecthood.

i.e. why make me go through the hoops of uri.get().execute() instead of just executeGet(uri), given that Request's mutability means can't meaningfully cache anything or hold onto any kind of heavyweight resource. You're currently just indirecting a function call through an object. Yew!

If you want to make it easy to manipulate URIs, then add a URIBuilder, or simply use copy-on-write, so that manipulating the URI returns a new URI. Seriously, this is a absolutely classic example of the kind of thing that should be immutable, along with things like strings, dates, numbers, etc. It's highly likely that people would want to share URIs between multiple threads, and at present that's not a safe thing to do.

Stuff like Query.addParameter(String, String) etc…

ceylon.file needs some kind of integration with the JDK's security model, user Principals and such. I suppose we need to work on ceylon.security.

ceylon.test depends on ceylon.collection because it needs a mutable Iterable thing to let you add tests to a test runner. We could easily rewrite it to use the ceylon.language.SequenceBuilder and drop the dependency.

Right now it does the right thing wrt equals(), but it requires computing a whole new BigDecimal, which will probably perform badly, so we should try to come up with a better algorithm.

Wasn't that the whole reason we added Exponentiable?

ceylon.file has no support for Links.

If I want to instantiate and populate a HashMap I currently have to do this:

value map = HashMap<Foo,Bar>();
map.putAll(foo->bar);

I'd like to just have to do this:

value map = HashMap<Foo,Bar>(foo->bar);

The following code:
MutableMap<String, String> testMap = HashMap<String, String>();
testMap.put("one", "ein");
print(testMap);
testMap.remove("one");
print(testMap);

produces:
{one->ein}
{one->ein}

instead of:
{one->ein}
{}

My idea is that in HashMap.remove() instead of:
last.cdr := cell.cdr;

the following is needed:
if (last == cell) { store.setItem(index, null); }
else { last.cdr := cell.cdr; }

It worked for me for a few simple test cases

The methods put and remove of MutableMap should return the replaced/removed element, if any.

I think the mutable collections should have fail-fast iterators which detect when the collection being iterated over is changed partway thought the iteration. It's not a very common programming error, but it makes for some really hard to find bugs if the iterator doesn't fail.

@matejonnet I have a couple of questions:

1. Do we really need WebEndpoint at all? Why can't it just be a function of type Anything(Response,Request) or even Response(Request)?
2. Why is WebEndpointConfig an interface with a factory method? Why not a concrete class?
3. Why does WebEndpointConfig point to WebEndpoint using strings?!

Currently it seems that I'm forced to write all this stuff:

shared class MyEndpoint() satisfies WebEndpoint {

    shared actual void init(WebEndpointConfig webEndpointConfig) {}

    function name(HttpRequest request) => request.parameter("name") else "world";

    shared actual void service(HttpRequest request, HttpResponse response) {
        response.writeString("hello ``name(request)``!");
    }

}

void runServer() {
    value httpd = newInstance();
    httpd.addWebEndpointConfig(newConfig { 
        path = "/"; 
        className = "jdbc.MyEndpoint"; 
        moduleId = "jdbc";
    });
    httpd.start { port = 8080; };
}

When all I want to write is this:

void runServer() {
    function name(HttpRequest request) => request.parameter("name") else "world";
    value httpd = newInstance();
    httpd.addWebEndpoint(WebEndpoint {
        path = "/"; 
        void service(HttpRequest request, HttpResponse response)
                =>  response.writeString("hello ``name(request)``!");
    });
    httpd.start { port = 8080; };
}

I don't see what all those indirections buy me...

LinkedList is bugged when removing last element in list:

value list = LinkedList<String>();
list.add("A string");
list.remove(0);
list.add("Another string");
print(list);

This will print "[]". The reason is that the tail in the LinkedList is not set to null when last remaining item in list is removed.

Considering the recent changes concerning variadic parameters the parameter type of MutableList.addAll should be changed from Element... to Iterable<Element>. And MutableSet.addAll and MutableMap.putAll should also be changed correspondingly.

The SDK is going to need a nice way of writing tests, so we're going to need a testing framework, even if it's not part of the SDK itself.

It should be possible to run the tests through Eclipse and through Ant.

The title says it all.
The doc should state clearly that calling "close" on a Writer should trigger "flush" as an additional operation before actually closing...

The sample usage code is so wrong it's not even funny how lame it is.

ceylon.file doesn't have any support for getting/setting permissions or file attributes.

Last week I tried to get the Herd upload working (the herd-module target), but I kept getting a 404.

The SDK build doesn't copy the module org.jboss.modules anywhere where the IDE can find it, so importing ceylon.net now results in a build error.

There should be a way to watch for changes to a file or directory.

In ceylon.math.float, we have sum(Float... floats), product(Float... floats), min(Float x, Float y), and max(Float x, Float y). We need these same four functions, but for Integers.

Or should we move this functionality to ceylon.language, and name the functions floatSum(), integerProduct(), largestFloat(), smallestInteger(), etc?

WDYT?

Stef's done a mess of things with stuff like URI, we should go for Uri style for acronyms, to be consistent. Also some methods are called parse (JSON) while others are called parseURI, so a little consistency would help.

Add operations for getting/setting the owner of a resource, and an API for looking up principals.

Each function should describe how it behaves wrt undefined, infinity, -infinity plus any function-specific special cases.

Currently there is no direct option to remove an element from a list.

We should implement:
shared formal Boolean removeElement(Element val);

ceylon.net has an ugly dependency on ceylon.json because Stef wanted to do URL('http://example.com).getJSON(). We need a more general pluggable URL retrieving mechanism (which can be shared with ceylon.xml for example)

Currently the build is an ugly mess which doesn't work most of the time. I want to explore how we can improve this situation.

My first idea was to just have a single build file and compile (doc, test) the modules all at once, like this:

<ceylonc executable="${basedir}/../ceylon-dist/dist/bin/ceylon"
        out="${repo.out}">
        <module name="ceylon.math"/>
        <module name="ceylon.collection"/>
        <module name="ceylon.file"/>
        <module name="ceylon.io"/>
        <module name="ceylon.json"/>
        <module name="ceylon.net"/>
        <module name="ceylon.process"/>
        <module name="ceylon.dbc"/>
        <module name="ceylon.interop"/>
</ceylonc>

That works. It's conceptually much simpler. It's also quicker than the existing build, both when doing a clean build and also when doing a rebuild because of the default laziness of <ceylonc>. The problem is we end up repeating all those <module>s (e.g. for ) plus the related set of test modules (e.g. test.ceylon.math).

My initial response to that was "Let's have a <moduleset> with an id attribute which we configure to the top level of the <project> and can refer to in a particular task via a <moduleset refid='...'>" (i.e. like ant does with <fileset>s). That helps for compile and doc but it doesn't help with testing because ceylon run takes a single module, not a list of modules, so we end up having to repeat lots of <ceylon> tasks to run each of the tests separately.

One way around that would be to have a dedicated ceylon test tool, which did take a list of modules to test. It's not really clear how it might differ from ceylon run in other respects though. Here are some ideas:

• It could be a higher level tool, responsible for compiling as well as running the test modules.
• It could report an aggregated set of test results instead of stopping with the first failing module
• It could run test modules in parallel
• It could apply a convention about the naming of test modules wrt the modules they're testing

An open question about a ceylon test tool is: Does it take a list of modules to be tested, or a list of test modules? What I mean by that is at the moment the SDK applies the convention that ceylon.foo is tested by test.ceylon.foo, so the test modules (test.ceylon.*) are a different from the modules to be tested (ceylon.*). It doesn't need to be like that, of course.

An alternative would to to have to tests for ceylon.foo be in ceylon.foo, just in a different source directory so it was possible to compile the sources in both directories to a test output repo, and compile just the real sources again to a separate publish output repo. The benefit of doing that is it's possible to test things which are not visible outside the module. The drawback is you end up having to compile the same module twice. There's also the problem of how you declare the dependency of you test code on the test framework without polluting the module descriptor for the real code with that dependency, which looks like a similar problem to ceylon/ceylon-spec#499 only unrelated to backends.

A directory can potentially contain a whole lot of files.

I think this is the correct implementation:

doc "Removes an element from this set, if present"
shared actual void remove(Element element){
    Integer index = storeIndex(element, store);
    variable Cell<Element>? bucket := store[index];
    variable Cell<Element>? prev := null;
    while(exists Cell<Element> cell = bucket){
        if(cell.car == element){
            // found it
            if(exists Cell<Element> last = prev){
                last.cdr := cell.cdr;
            }else{
                store.setItem(index, cell.cdr);
            }
            _size--;
            return;
        }
        bucket := cell.cdr;
        prev := cell;
    }
}

The original plan for Whole and Decimal had them supporting single quoted literals to allow you to specify a literal value. However, single quoted literals are now scheduled for Ceylon 1.0. So we're going to have to use String literals instead.

Ideally we would provide parseWhole(String) and parseDecimal(String) methods, similar to what ceylon.language does for Integer and Float. That would require the initializers to accept either ceylon.language.String or java.math.BigInteger/BigDecimal though. The former defeats the purpose of having the parse* methods and the latter just seems ugly and very Java specific. The final option would be to write ceylon.math in Java where I can overload and hide the constructor that takes a String/BigInteger/BigDecimal.

Can anyone think of a better way?

ceylon.net contains the interop functionality from Stef's iop module, because that was the simplest thing to do to get it working. We should go back and remove those things which are nolonger needed (some will be M2-isms)

So I figure that we're going to need some kind of Path type, with all the usual convenient operations for manipulating filesystem paths. But beyond that I'm not totally clear on what other things we need. Clearly we need a way to distinguish between the different kinds of things that a path could refer to:

• directories
• files
• nothing

What else? How do we work symbolic links into the above taxonomy? Are they a kind of file?

And how should we present this via the API:

• as path.type that returns directory, file, or nil, or
• as a path.resource that returns an instance of Directory, File, or Nil.

The second option feels better, since it gives us a place to group together the operations that make sense for a particular kind of resource. Otherwise we would just wind up with a bunch of toplevel methods that operate on Paths. OTOH, it forces us to go to the filesystem to determine what kind of thing we have before we can attempt to do anything useful with a Path.

Finally, what is the model for reading/writing to a File?

ceylon.math.float has a lot of functions which have Float-valued parameters. It would be nice if we could use these functions with any type which could be safely widened to a Float, so for example I could write sqrt(2) rather than having to write sqrt(2.0).

ceylon.file provides no facilities for reading/writing binary data. Stef and I talked about this and we think there should be a separate module (ceylon.io, or ceylon.binary) with this kind of low-level stuff.

It seems publish.repo does not get defined and has to be set explicitly on the command line

OK, so with the latest changes the SDK won't compile against the current version of the language module.

We need to do M3-compatible changes in a branch, and keep the head of SDK working against head of the language module.

ceylon.net depends on ceylon.io, but ceylon.io's tests depend on ceylon.net. This raises several problems:

1. A top level ant clean test fails, because the dependency of the test goal to the compile goal is expressed in common.xml (i.e. the module build file). This can be worked around by doing a top level ant compile first.
2. A top level ant local doesn't work because that looks for dependencies in the 'local' repo (~/.ceylon/repo), and tries to be clever by checking that the modules compiles, tests and docs OK before doing the real compile into the local repo.
3. A local ant local-module in either ceylon.io or ceylon.net also fails, because of the cyclic dependency.
4. Presumably there are herd problems similar to the local problems.

We should really be compiling everything before testing. In other words, we should have <target name="test" depends="compile" ... in the top level build.xml. The reason we don't is the build has always tried to support building everything at once and building a single module, so we need the same depends= in the common.xml. But actually having both means we'd end up doing the compile twice, and still wouldn't solve the local/herd problems.

A work around to the problems with ant local is to drop the extra safety checks and let people deploy stuff to their local repo that fails tests and/or doesn't doc properly.

The wider problem is that the ant build just isn't working at the moment. The ceylon tools let you say which module(s) you want to compile/doc etc, but ant requires us the embed this somehow into a build file, which means we lose the ability to say what it is we want to compile, which is what necessitates having build.xml and common.xml.

see test https://github.com/ceylon/ceylon-sdk/blob/master/test-source/test/ceylon/io/testDecoder.ceylon#L70

According to the docs for String.normalized (http://ceylon-lang.org/documentation/current/api/ceylon/language/class_String.html#normalized) leading and trailing whitespaces should also be removed: "...and discarding whitespace from the beginning and end of the string", i.e. every normalized string is also trimmed.

So the following assertion should hold (or the docs are wrong):

void testNormalized() {
    value normalized = " Hello World ".normalized;
    value trimmed = normalized.trimmed;

    assert (normalized == trimmed);
}

but I get

ceylon run: Fatal error: Assertion failed violated normalized == trimmed at NormalizedString.ceylon:5:4-5:34
ceylon.language::Exception "Assertion failed
    violated normalized == trimmed
    at NormalizedString.ceylon:5:4-5:34"
    at testNormalized_.testNormalized(NormalizedString.ceylon:5)
    at testNormalized_.main(NormalizedString.ceylon)

Tested with:
ceylon version 0.4 (Analytical Engine)

The following code prints http://ceylon-lang.orgblog

URI uri = parseURI("http://ceylon-lang.org");
uri.path.add("blog");
print(uri);

We need to do this.