Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


+ - New Opa S4 release puts forward new "ORM" for MongoDB->

Submitted by phy_si_kal
phy_si_kal (729421) writes "The new, open source, Opa web programming language just hit version 0.9.0 "S4", six month after its last major release.
Apart from a new syntax more similar to JavaScript, the new releases focuses on mongoDB integration.
Opa now features something similar to ORM except that mongoDB is a non-relational, document-oriented database and Opa a functional, non-object-oriented language.
The new functionality makes the NoSQL database even easier to use as all language-database calls are automated. And the mapping of functional datastructures to documents could even be much better than current ORM approaches and solve the object-relational impedance mismatch."

Link to Original Source

Comment: Re:threads (Score 1) 253

by cedrics (#37234942) Attached to: Announcing Opa: Making Web Programming Transparent

Even if the fibers are small, they may invoke kernel calls which take a long time to complete (for example a large I/O operation). How do you ensure that other fibers can continue their work in such cases?

For example, to write a large file over the network, the scheduler write small piece of data at a time. And all socket are on non-blocking mode. So if the read/write operation would block, the OS just raise an "would block" error, and the scheduler use epoll to check back later.

To call synchronous function, there are solutions like forking the operation into on an other process. And there are different solutions for the process-communication : pipes, sockets, hlnet (our home made protocol used by our distributed DB), rest, soap...

Further, the smaller your fibers get, the more overhead you introduce for context-switching, right? Because I can imagine that after execution of each fiber you need to do some scheduling (even if the current fiber remains active). Is this context-switching faster than the kernel can do it?

Finally, I'm interested in what makes scheduling for the web such a specialized task, but that may be related to the previous question.

By "specialized", I mean it's better that fibers are scheduled by the application-scheduler itself, that knows the logic of the application and the purpose of each fibers, rather than the OS-scheduler. About context-switching, there is the small context-switching between fibers inside the main-thread, and the bigger context-switching between this mean thread and the others thread of the OS. So it really depends here on what we are trying to compare (and if it's comparable).

Comment: Re:threads (Score 1) 253

by cedrics (#37234382) Attached to: Announcing Opa: Making Web Programming Transparent

Don't forget that the compiler transform your code to a CPS representation. So in practice, your OPA function is "cut" into many very very small fibers. So, even if we are talking about non-preemptive fibers, the high-level user function can be stopped by the scheduler at any time to take car of new I/O events.

It's the scheduler job to balance all those small fibers (that belong to several high-level functions) to optimize the latency level. And the web-specific scheduler does this job better than the generic OS-scheduler.

Comment: Re:threads (Score 1) 253

by cedrics (#37233622) Attached to: Announcing Opa: Making Web Programming Transparent

Hi StripedCow, I'm one of the guys who wrote the OPA scheduler so I'll try to answer your scheduler-related questions. It uses fibers (co-operative light threads). The compiler transforms your code to a CPS representation, so our scheduler can balance the pool of computation stuff and I/O operations (we use epoll on Linux, kqueue on Mac OS). The developer can explicitly push asynchronous tasks with a simple Scheduler.push https://opalang.org/resources/doc/index.html#scheduler.opa.html/!/value_stdlib.core.rpc.core.Scheduler.push
OPA doesn't yet offer to the developer the control of the priorities.

So as you can understand, it doesn't rely on the OS-scheduler, there is only one main OS-thread for all computations and I/O clients (our scheduler does the job). A common question is how to use all cores of a multi-cores machine? Well, just launch the app one more time and use your load balancer (or use our cloud tool).

The code is open-source, scheduler included ;)

Comment: Re:Opa = OCaml + "rails" (Score 2) 253

by cedrics (#37233046) Attached to: Announcing Opa: Making Web Programming Transparent

Compiled their 76-line hello_chat.opa into a 30M executable

In those 30Mo you have just everything (the web server, the database engine, the scheduler, the page engine, the session engine, your webpages source, css, the generated js, etc) ! It's a standalone binary that just works on your server without having to install anything more. Did you check the size of the LAMP / Java / Ruby packages?

I would love to see some eCom or other complex sites written in opa to convince me that this is a viable alternative to Ruby, Java, PHP, etc.

MLstate did launch an eCom-like site : http://jetleague.com/ And I just check the binary on our server: 17Mo (yes, I guess it has been upx-ed)!


+ - Announcing Opa: Making web programming transparent->

Submitted by phy_si_kal
phy_si_kal (729421) writes "Opa, a new opensource programming language aiming to make web development transparent has been publicly launched.
Opa automatically generates client-side Javascript and handles communication and session control.
The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces.

Among existing applications already developed in Opa, some are worth a look.
Best place to start is the project homepage which contains extensive documentation while the code of the technology is on GitHub. A programming challenge ends October 17th."

Link to Original Source

+ - Opa: new web development platform->

Submitted by
koper writes "Opa is a new generation of web development platform. It is a new programming language, a new web server, a new database and a new distributed execution engine, all of them tightly integrated to provide a great experience for web developers. Few days ago it became open-source.

Why should you care about yet another language? There are few things that make Opa stand out from the crowd:
  • it's a language targeted at the web;
  • it puts lots of emphasis on security;
  • it's a one-stop solution; you write in Opa and it generates for you: the client-side code (JavaScript), database queries, all the glue code etc.
  • scalability won't be a problem: your app is distributed and cloud-ready right from the start.

Curious? Sounds too good to be true? Check out Opa's homepage or my blog for more info.

Disclaimer: I am working on Opa at MLstate."

Link to Original Source


+ - A new, original, open source web tech is born-> 1

Submitted by phy_si_kal
phy_si_kal (729421) writes "Today, a secretive startup from Paris, France has announced that it will open source the Opa technology it has been developing for some time.
Opa is a one-tier web technology (right, that means only one layer at runtime) where Opa source code is compiled into a standalone binary. And, this could be really a game changer in the cloud era as it handles distribution very easily.
Sadly, the code is not yet available but a 171-page manual and tutorial is already available (registration required) and packages seem on the wild.
Disclaimer: I am at MLstate (and very happy)"

Link to Original Source

Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein