Gravel
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 199 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32537 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Execution unitLine (geometry)BitFormal languageXMLLecture/Conference
00:46
Digital rights managementCartesian coordinate systemTrailWeb applicationComputer animation
01:30
QuicksortMereologyWeb applicationCartesian coordinate systemGraph (mathematics)Execution unitCodeWeb 2.0Lecture/Conference
01:58
CodeJava appletSoftware bugProcess (computing)Computing platformLibrary (computing)WordComputer animationLecture/Conference
02:45
Video gameSoftware developerComputer configurationAlgebraic closureComputer animation
03:19
Exception handlingOpen sourceProjective planePoint (geometry)Goodness of fitMachine visionAtomic numberOperator (mathematics)Particle systemInsertion lossCompilerSemantics (computer science)BitParsingInstance (computer science)HD DVDContext awarenessXMLComputer animation
04:53
Computer configurationSource codePhysical systemDialectType theoryParameter (computer programming)AbstractionTexture mappingPointer (computer programming)2 (number)Java appletDifferent (Kate Ryan album)Euler anglesProcess (computing)Lecture/ConferenceComputer animation
06:28
CompilerObject (grammar)Library (computing)Computer networkIntegrated development environmentElectronic mailing listInteractive televisionPatch (Unix)Java appletReal numberPhysical systemXML
07:31
CompilerMereologyPatch (Unix)Perspective (visual)MassOrder (biology)ChainMathematicsCodeGame controllerLecture/ConferenceComputer animation
08:14
QuicksortLibrary (computing)Communications protocolMereologyInheritance (object-oriented programming)Physical systemResultantVirtual machineBasis <Mathematik>Form (programming)WordView (database)Right angleSoftware testingVisualization (computer graphics)CircleSource codeObject (grammar)Level (video gaming)Network topologyInformationMessage passingOrder (biology)Type theoryNormal (geometry)CodeFile formatImplementationLecture/ConferenceXML
11:29
ImplementationDefault (computer science)InformationOrder (biology)Greatest elementQuicksortProcess (computing)AreaIdentifiabilitySocial classInsertion lossoutputJava appletLogicElectronic mailing listPhysical systemLecture/Conference
12:39
Software developerPoint (geometry)Library (computing)Software testingMereologyCommunications protocolStandard deviationPhysical systemLie groupComputer fileTheoryForm (programming)Computer animation
13:24
InternetworkingComputer programmingUnit testingForm (programming)Lipschitz-StetigkeitProcess (computing)Web browserPhysical systemAdaptive behaviorImplementationPower (physics)Java appletSoftware testingPoint (geometry)Lecture/Conference
14:18
Video gameLimit (category theory)Instance (computer science)Network topologyPoint (geometry)Formal languageQuicksortSummierbarkeitComputer animation
15:49
QuicksortInstance (computer science)Machine visionCompilerMereologyPoint (geometry)CodeMathematicsType theoryJava appletLecture/Conference
16:51
Multiplication signDemo (music)Open setIntegrated development environmentSpeech synthesisEvent horizonComputer networkIdeal (ethics)Computer programmingOpen sourceXMLComputer animation
17:35
AreaXMLProgram flowchart
18:13
Electronic visual displayMereologySubsetWordCodePhysical systemIntrusion detection systemSocial classSource codeFeedbackView (database)Web applicationQuicksortWeb browserBenchmarkMultiplication signJava appletMathematical optimizationUser interfaceNumberRepresentation (politics)Ocean currentProjective planeDemo (music)File formatVideo gameField (computer science)BuildingPhysical lawSet (mathematics)Staff (military)MathematicsAreaProcess (computing)Rule of inferenceCartesian coordinate systemFrictionLine (geometry)AdditionLecture/ConferenceComputer animation
23:47
Product (business)Projective planePhysical systemType theoryCodeSource codeSoftware testingMereologyQuicksortLecture/Conference
25:19
Multiplication signSurgeryGreatest elementChainAdditionRepresentation (politics)Right angleComplex (psychology)Online helpExecution unitResultantPhysical lawSound effectImage resolutionFormal languageCuboidBitTotal S.A.Power (physics)LengthXMLUML
30:09
Ring (mathematics)Electronic visual displayCuboidImage resolutionSet (mathematics)Insertion lossDifferent (Kate Ryan album)Dimensional analysisDigital rights managementComputer animation
32:07
Perfect groupGoodness of fitMultiplication signComputer animationLecture/ConferenceXML
32:37
Multiplication signComputer animation
Transcript: English(auto-generated)
00:03
First, a quick question for all of you. Whom of you have used Smalltalk in the past or are using Smalltalk? So I'm going to do some in-depth things of Smalltalk. So it would be handy if you would know a bit of Smalltalk.
00:22
And I should just ask. No, I've seen enough of two presentations. Yeah, I don't use Smalltalk at all. You should. It's a very fun language. Yeah, I just came to Smalltalk.
00:41
First, a quick introduction about myself. I'm Walter Haselan. I'm the co-founder of AG5. We're a full Smalltalk company since 2000. So we've been doing non-stop Smalltalking for almost 13 years, I think.
01:03
In the past, we also used the name Cosmo Cows. Perhaps some of you may remember that one from the past. And we are based in Amsterdam and Berlin. And AG5 develops a web-based skills management application.
01:25
It's a very complex application and we keep track of how good people are trained for all sorts of highly trained professions. Fire departments, industrial safety and stuff like that.
01:42
So in the past, we built a huge Smalltalk codebase, which we still are supporting in a web-based application. And this leads us to the part why we started, actually, Gravel. Because we have lots of Smalltalk code and we want to run on Java.
02:05
And we are not going to rewrite that because that will take many, many years. And we will introduce many bugs. And I don't like Java. I like programming Smalltalk. The main reason we currently are looking away from Visualworks to another platform
02:24
is we want to have good multi-core support and we want to integrate with the whole Java library infrastructure with all the good stuff that is made out there.
02:40
So what is Gravel Smalltalk? Gravel Smalltalk is a Smalltalk that is running on the JVM. We implemented using the now infamous info-dynamic instruction that is new in Java 1.7.
03:00
It was introduced by the JSR292. And we tried to develop Gravel Smalltalk itself, the JVM infrastructure in Smalltalk, the whole Gravel infrastructure. And we have lots of features like trace namespaces, optional piping, closures
03:20
that are working correctly, and resumable exceptions. And we open sourced the project under an Apache 2.0 license, which we may change because some people are saying that the MIT license is better at good.
03:41
I disagree. We also have some things in Gravel clearly absent. If you are coming from a Smalltalk world, sometimes you may know the become operator or the all instances operator
04:00
or the special arrival disk context. Currently, we do not support that in Gravel Smalltalk. And the main reason is performance. To correctly implement those semantics in Gravel Smalltalk on the JVM would mean that we would lose all the speed benefits of what the JVM can do for us.
04:24
If we find a good way to implement it, we might change it. I am going to tell you a bit about the Gravel internals. First, how we actually developed the compiler infrastructure of Gravel itself.
04:47
We started developing Gravel in Visualworks, and we all built a parser compiler infrastructure in Smalltalk itself. We once developed a type annotation system, an optional type annotation system,
05:03
that was inspired by Strongtalk called EAGAN. It allows us to add type annotations to Visualworks source code. We use that to transform the Smalltalk source code to Java source code.
05:22
I have a small example over here, which actually wraps around the screen. I have a method called method mapping for selector. I am going to see if I can move the image actually on screen.
05:51
Above is the method mapping from selector. This is the Smalltalk source. It is annotated with those curly braces type annotations.
06:06
These are the parameter types, and this is the return type, which is abstract method mapping for nil. This is the Smalltalk source, and it will generate this Java source out of it.
06:22
Let's see if I can get my window back. We tried to develop as much of the system in Smalltalk itself, because I don't like Java.
06:44
We developed a patching compiler, with the idea that in an interactive Smalltalk environment, you would like to change behavior when you are developing in it.
07:01
We would like to use Java objects that come out of the libraries that we use, like some list comes out of a library and it enters the Smalltalk code, and we want to use that array list as a real Smalltalk object. You would like to be able to detect or select
07:25
one of the acts on those kinds of objects. You cannot hot-add methods on the JVM, and we want to be able to change all kinds of things, so we started a concept called the patching compiler.
07:41
The patching compiler allows us, from the Smalltalk perspective, to add and remove and change behavior. It is purely because the JSR gives us full control over the method lookup, so we can decide that some old method is no longer valid from our Gravel perspective,
08:05
and now a new method or a different method is valid, or the lookup chain has changed. This gives us the possibility to change Smalltalk code on a running JVM.
08:22
Next, to get Gravel running, we need some sort of base library. What we actually are doing is we are using the SP80 base classes from Squeak,
08:41
and we are getting those source codes from Squeak, and importing them in special packages in Fisherworks, and then write all those codes out of Fisherworks again.
09:01
We found this great package called the ANSI DEDE. It is actually a machine-readable format of the whole Smalltalk ANSI standard, which describes what kind of protocols you can expect in a normal Smalltalk system, and what kind of selectors should be implemented,
09:21
and what kind of behavior there should be. We use that to ultimately generate tests, and actually we don't test that much. You see a generated test over here that runs with some example values,
09:41
so this is the test for the selector called ASBag, and certain kinds of objects should be able to respond to a message like that, things like an order collection, or an array, or other collection types.
10:01
So values will iterate over some example values. We just perform the selector and test whether the result is anything sensible. So we don't do any semantic checks, whether the result is anything sensible next to a simple type check.
10:26
Using these tests we can pretty easily recreate what is needed to have a base Smalltalk system in Gravel.
10:41
And what we need, we copy from Squeak, we then split things up if the definition is part of the trade part, what we call it, or the actual implementation part.
11:03
Because in Gravel we use the trade system, and in Gravel we think that an order collection defines something of the public protocol of the base library.
11:21
So the order collection, from our view, is a trade. So the actual implementation of the order collection is a class you wouldn't instantiate yourself normally, it's an order collection input, and that contains the actual private logic for using this order collection.
11:48
Order collection input is the default implementation for this trade, so sending order collection new will yield an order collection input. Most of the implementation comes from Squeak.
12:02
We can also use these traits that we have built to look at the Java environment, and if we identify certain Java classes that sort of correspond to folder classes, then we can have the, for example, the Java utility array list,
12:25
we can have it conform to this trade, so that every utility method that you will add to the order collection trade will be available on an array list that will enter your Gravel system.
12:42
We started the development of Gravel in October last year. At this point we have the generated ANSI tests working, which means that the largest part of the base library is working. That's actually a lie because we don't have the file protocol tests working,
13:04
and that's because the ANSI standard has a very weird thing about file protocols, and I think Squeak and VisualWorks also don't conform to the ANSI standard in that respect.
13:22
We also have ported some libraries to test the system. We could, with very little adaptation, we moved S-Unit to our system, and we used S-Unit to run tests on Gravel small talk.
13:41
I somewhere found an implementation of DeltaBlue on the internet to check the performance of Gravel small talk, and I found an implementation of the Richards benchmark, and we actually started on the first idea of the Gravel IDE, because I don't actually like programming in Java now,
14:02
I also don't like programming in Eclipse. I really love the power of the refactoring browser, of using a debugger, and things like that. So, things we have not done at this point yet.
14:25
First thing is we want to look into trouble. We have Stefan Mar. We're very interested in what the sum actually is going to do, so that's something we really like to experiment with, because it looks like very promising technology.
14:47
Another thing we really want to do, because we have the luxury of being a very new language, so we don't have to do things like support and stuff, is do something good once and for all,
15:02
and that is kill all the globals in a way that Newspeak does, because I really like small talk, but I don't like globals in small talk. What we also have to get working is the live debugging.
15:23
The problem with live debugging is the limitations of the JVM. You cannot, in an image itself, you cannot re-instantiate the stack, for instance. You can only monitor the stack from an older JVM,
15:42
via a sort of debugging port. There are some tricks possible, how we can get live debugging working. It's hard. We're working on that. If anyone has a good idea how to get really good debugging on the JVM,
16:03
I'd really love to hear it. Next step for us is, if we can work in Gravel itself, we will make it self-hosting, so that some parts of the code, for instance the code that transforms
16:22
the type annotated compiler where small talk to Java is currently visual only, so if you would somehow change the compiler, you cannot generate it in Gravel itself at this point.
16:41
So that sort of concludes what Gravel is today and where we hope we will be going. I'd like to say thanks to, well, it's about saying thanks to the whole idea of open source, because we couldn't have built this in a few months time
17:04
if there wasn't that enormous amount of ideas freely available on the net, like the whole small talk squeak environment and the JSR stuff and everything over here. I'd also like to thank the FOSTAM people
17:21
for giving me the opportunity to give a speech over here. So, thanks to that. I'll give a short demo of Gravel's small talk.
17:41
We'll first switch my monitor back into, does anyone know how to get the Mac
18:00
to monitor my screen over here? Do I see that button over here? On the screen? It's always on the other screen. On the other? It's also not over here actually. Arrangement.
18:21
Arrangement. Mirror displays. Okay, thank you. That's better. I'll get Eclipse.
18:42
I hope this is readable for you. Over here I have one Maven project that contains all the Gravel sources over here. It contains the Java code and the small talk code.
19:00
Actually, those folders are a representation of FisherWorks packages. I'll try to start the web browser because that's the most interesting part. May I interrupt?
19:21
Yeah. Did you take a look at Redline's project? Yeah, I did. Redline has a different approach. Our approach is mainly about speed and Redline is not that focused on speed. So that's the reason why we didn't go the Redline way.
19:41
But you didn't mention any speed numbers. I'm actually a bit cautious about naming speed numbers because I don't know how to do official benchmarks and stuff. What is actually interesting, but those are unofficial numbers,
20:00
we have the DeltaBlue benchmark running faster than the Java. So we can run the DeltaBlue code on the JVM in small talk faster than the Java code is running. All thanks to the great hotspot optimizations.
20:23
Then again, you also showed this problem with the richest benchmark and it really performs like hell on our system. It's really bad. It's like a hundred times slower than Java.
20:42
Any well-known problems? I'm running out of time over here. I started my browser.
21:01
The browser connects to Gravel Smalltalk. We've built this browser to actually get a view of the system itself. So it's a web-based sort of browser we have over here. On the left-hand side you have the packages and there you can see all the classes
21:22
that have been implemented. And you can view some source code. What we actually can do is add a method like foo and accept it. And it actually appears over here as the method foo.
21:44
So now I have added the method foo to fraction. It's of course hard to get some feedback in a system when you have no debugging working. So I'll go the classical way of crashing your own IDE.
22:06
I'm now viewing at the browser application class and the browser application class is the actual thing you are seeing right now. Somewhere over here is a button called accept.
22:22
And I like to use the French word for cheese. So when I accept this code and it actually accepts it, my button is now called fromage. So I changed the source code of the code that renders the user interface
22:45
and now the code, the method is changed. As you also can see is that the formatting of the method has changed and that's because it's now a sort of decompiled code because we currently don't yet write back
23:02
the changed source code to disk. So it's now decompiled code. So that's a quick demo of the Gravel system, well a small part of the Gravel system.
23:26
Are there some questions? How many people are working on this? Currently mainly myself
23:41
and a colleague has put in some extra hours mainly in analyzing the Squeak code to get the actual methods that we have to move over to Gravel because we don't want to move over all the methods because there's all sorts of legacy methods in them
24:01
so we only want to move over the methods that are needed to satisfy our tests. So it's I think one and a half guy.
24:24
Other questions? Are you already using this in production or is it? We are planning to have it in production somewhere in first small systems in March
24:41
or things like that. So we first started this as a research project to see if it was actually doable and now that it seems to be doable we will be using it in production.
25:02
Okay, thank you.
26:24
Can you tell us the total length of it? Yeah, yeah, yeah. The length of it is a good bar.
26:41
10 to the 24 times 70 feet.
27:15
You can see all the way inside. You just pick a minute.
27:36
I'm going to check this.
27:57
Which resolution do you think the language is?
28:03
10 to the 24 times 70 is 68. I don't know why this box only takes one resolution.
28:21
Yes, they asked for the sheets to be at 800 times 600. Yes, that's right. Okay. No, it doesn't matter. Yeah, my problem is that I'm using a virtual box. It's not that easy.
28:41
I need to change both. Okay, we'll do something else. I think you could use a bit of power.
29:03
Do you have the old style? Yes. No? Yes.
29:25
So this is why we have five minutes between the box. It's simply needed to get those resolution things to work out.
29:48
Okay, and that one needs to be broken. 60 hertz is nice, I guess.
30:02
Black, should it be 60 hertz or should it be higher? 60 hertz, okay. So now, some white. Do you have middle ring on? Do you have some middle ring?
30:22
Middle ring? Well, this display is going to be dead. I don't know why. Do you have any display? No display yet?
30:41
Okay. It's on the Mac side. Yes, actually it was in different resolutions.
31:03
We tried five minutes. Okay, it's okay like this? You have five minutes. In five minutes we'll try it. Okay, just try it. But it's okay? The box is on.
31:26
Everything is green, so I should suppose that it's created with the hertz. Maybe with the...
31:41
It's on the Mac side. In the Mac side. Display settings. There it is. There are more hertz.
32:01
We can change. That's it. Better? Okay, good. Perfect.
32:22
So, after a few minutes of technical issues, I'm happy to...