Ok, rym ni'n rhaid i'u wneud am ymdano. Rwy'n rhaid i'n rhan o'r Serer. Serer yn y designer, y developer, ac yn y self-convestigle. Mae'n gwaith i gynnugol o'r oedd ymwneud. Bydd o'r hyn a'r gweithio'r thymau. Fy enw i'n mynd i'n gweithio'r hyn o'r hyn. Serer oedd mewn cyd-oedd o'r hyn o'r hyn o'r hyn, o'r cyd-oedd o'r hyn o'r hyn o'r ffordd ac oeddennydd nhw. a dyna ei wnaeth a gwneud i mi'n gwlad i gael'r ysgrifennu. Felly, rwy'n gweithio chi'n gweithio'r tynnu i'r bywyd. A ydw i'n gweithio'r mwy o'r gweithio'r tynnu i'r bywyd. Felly, mae'n bwysig i'r gweithio'r bywyd. Felly, mae'r techniclu'r bywyd. Felly, mae'n gweithio'r tynnu i'r bywyd, sydd wedi gweithio'r bywyd. Ydw i wnaeth chi gweithio'r bywyd. Website that look like this, and this, and this. They all sort of follow the same pattern. At the top, you have a logo on the left and navigation to the right. Beneath that, you have a full width hero header image. On top of the hero image, there's sans serif type, usually white, and a big flat button that's used as a primary call to action. Below that, you have a column of featured items, often three, and always illustrated with an image, photo, or icon. And this looks nice. It works well. But it's so common as to have become a cliché. These are websites for different things. They're communicating different messages. Education software isn't the same thing as a water filter. When everything looks the same, how do we distinguish between them? So the web didn't always look like this. So we're going to take a look and see how we ended up here. How many people here got into web design relatively recently over, say, the past five years? Okay. What about the past ten years? Has anyone been doing it for longer than ten? Wow, that's a lot. Okay. So for some of you, this is going to be a blast from the past. And for others, this will be a chilling vision of the future, of the past. The internet has been in development since the 60s. But what we know nowadays as the modern web is the worldwide web, and that really came about in the early 90s. And when it started, it was just text. The first website was published using HTML in 1991. It's still up, and it's just text as well. There are links to other sites, but there are no images, no colours, just text. It's still very early days here. In November of 92, there were 26 web servers in the world. That's it. By the mid-90s, our browser technology had advanced a bit. And we could do more. Nope, sorry. We could do more. We could embed images in our sites. We could use colours, not necessarily good colours, but colours. And we could use tables to start implementing layouts. At this point, the best way to design a website was to build a layout in Photoshop or in Design or Cork, and then slice it into component images. Every header text, every line needed to be its own image.  Invariably, to do more complicated layout, you'd need to nest tables inside tables inside other tables. You ended up with something that was a lot like code soup. And if you think that the code looked bad, the designs looked even worse. This wasn't a great time for websites. And we still didn't have CSS, so everything had to be declared manually using HTML tags. So in order to make every link on that page yellow, you'd have to define the colour for every single link individually. It was a lot of work to make something that looked this terrible. But everything at this point was quite new. And even bad tools are better than nothing. So we used everything we could get our hands on pretty indiscriminately. We used frames, we had hit counters, we put animated gifs everywhere. It was a new and exciting time for the web. The concept of building a personal site was completely new, being able to communicate with people on the other side of the world. And this is a really powerful thing. And in all that excitement, we sort of didn't develop any restraint. But things move along. And by 96, 1% of the global population was online. And CSS was introduced. And CSS afforded us more tools to control the way things look. This wasn't always a good thing. So you can change the browser's scroll bar properties to make it three times its original size and change the lighting effects and make it purple and yellow. And you can turn your user's cursor into a robot unicorn or have it shoot out sparkles or rainbows. There are actually multiple WordPress plugins that still do this. Don't look them up, please. Let's not forget the lessons taught to us by Spiderman. With great power comes great responsibility. But at this point, usability and accessibility wasn't really a big concern. We just wanted to make stuff that looked cool. Flash came out around the same time. And this allowed us to experiment more and also to have more control. We had a fixed box for our layout. We could use any typeface we had on our computer. We could position elements visually rather than manipulating them in tables. And we could play with animation. So this allowed us to design in a more visual way. By the early 2000s, things started to change again. The web was no longer a new medium anymore. And with increased knowledge and awareness of what we could do versus what we should do, this led to a refining of tastes. At this point, web design starts to feel like a thing. Websites begin to feel like they've been deliberately designed, like they're a cohesive whole. And we begin to see the rise of new and distinct trends within web design. One of my personal favourites was the Grunge trend. It used distressed textures, layered patterns, and lots of handmade elements to give an imperfect and tactile feel to sites. And the Web 2.0, one of the most poorly named trends in existence, was effectively the same idea but a different implementation. So it mimicked real-life objects as well. It used shadow and light effects. It used lots of gradients. Every button was either glossy or bevelled or both. And there was always a mirror effect, even if objects weren't sitting on a mirror. So both of these techniques were very image-heavy. And again, mimicked real-life objects. The iPhone built on these ideas. The first iPhone came out in 2007, and it presented a new challenge. Suddenly we had this new kind of device that was being introduced to a lot of users who maybe weren't that technical. So we needed a way to introduce, to teach those new users without alienating them, to teach them how to use the interface. So we saw the rise of skewmorphism. Skewmorphism is a derivative object that mimics design elements of the original. And what that means is this. If you understand how a book works, when you read a book, you pull the bottom right-hand corner in order to get to the next page, and then you build an interface that looks like a book. It has pages and a spine and maybe a ribbon down the middle. And when you touch the bottom right-hand corner of that interface, you move to the next page, that's what skewmorphism is. It's an affordance that links a new interface with an object that you already know how to use. And this allows users to intuitively learn an interface without having to read a giant manual. The popularity of the iPhone led to the adoption of many mobile devices. And suddenly we were reading the web on phones. And this led to the rise of responsive design around 2010 and another shift in design practices. Ultimately, as our technology changes, so does the way we design. And we needed now to scale our designs to lots of differently sized devices and different resolutions. We didn't have that fixed box anymore. It was hard to use a lot of images, and so we saw flat design come around. Flat design was actually pioneered by Microsoft with their Metro UI, which is now Microsoft Design Language. Metro ditched all-gradients, shadows, and it just used flat blocks of colour for everything. This approach makes it a lot simpler to adapt any design to different devices and resolutions. But in testing, they found that users miss things, important things sometimes.  So a lot of flat design today isn't totally flat. Material design is a good example of this. It's mostly flat, but it does use some shadow and light effects to differentiate important objects, like floating action button. Material design is a design language intended primarily for use in Google products, but I'm seeing it cropping up everywhere in themes and frameworks. Now, it allows non-designers to easily make something that looks good, but the trouble is it's rather prescriptive, and it's not intended to apply to everything. Bootstrap suffers from the same problem. For a long time it was a most-starred repo on GitHub. It's now, I believe, second most, so maybe it's waning in popularity. Bootstrap was originally called Twitter Blueprint, and it was just built as an internal tool for Twitter to use to rapidly prototype sites. So if you had an idea and you wanted to test if it had worked or not, you'd use this tool to get something up and running really quickly, and then if you decided you wanted to go further with it, you could go through a design phase. You can do lots with Bootstrap, and it's very easy to use it and make something that looks different and is individual and unique, but oftentimes people don't take that time to customise it, and the result is you can oftentimes see when something is a Bootstrap site. So the rise of flat design and all these new tools and frameworks gives non-designers an easier entry than ever into design. It's easy to build something that looks good without ever using a graphic editor or having a knowledge of the underlying design principles. And while ultimately that's a good thing, it can also contribute to the homogenification of the web. In order to build something that's great, you do need to have an understanding of design. Now you may think I'm not a designer, this doesn't apply to me, but if you make websites, if you pick out a theme for your site, if you hire a designer, if you choose colours or typefaces, you're making the web, you're involved in design decisions, and design isn't just about making stuff pretty. It's also about solving a problem. It's about understanding the needs of your client and your audience and communicating a message. There isn't any one-size-fits-all solution for every problem. Historically, designers and developers have been very different people with different approaches, priorities and goals. But more and more this isn't the case. It's rare to find a web designer who doesn't know HTML anymore. I like to think of web design and development as more of a spectrum than a binary. Most people in the field fall somewhere in the middle. It used to be that you'd have designers with a print background who'd build a layout in Photoshop and then they'd hand off the final files to a developer who would be responsible for implementation. But now, most web designers are aware of the technical constraints while they're designing a site, even if they don't do the implementation themselves. That prior knowledge of the technical constraints I think might be holding us back. Constraints often engender creativity. We devise clever solutions to work around them. But with web design we literally think inside the box. The technical constraints of the web require box-shaped elements, and so we build box-shaped sites. Modern web design is very literally stuck inside the box. Of course, to stay relevant as a designer, you do need to follow trends to some degree. What we find beautiful is very much shaped by our culture and by the zeitgeist, the spirit of the time. And this is evident in all forms of art and design, from fashion to music to architecture. There was a study done where they looked at Amazonian tribes who didn't have any exposure to Western music. Scientists had assumed that we had a biological preference as humans towards harmonic sounds, but when they played music for these Amazonian tribes who hadn't heard any Western music, they found that there wasn't any preference for harmonic over discordant sounds. And so an understanding of the world and its current aesthetics and your culture is vital to remaining relevant. The flip side of that, of course, is that an over-reliance on trends means a design becomes dated very quickly. Think about the swish logos that were ubiquitous in the 90s or those glossy buttons of Web 2.0. And following those trends really closely is fine if you want to redesign a site every year, but most of us don't have time for that. It's worth noting. A standard UI conventions aren't the same things as trends. This is how users find things. It's how they make sense of an interface. Don't rewrite convention just for the sake of it. The Nielsen group found that if you moved a logo from the top left-hand corner of the page, it was actually six times harder for users to navigate to your homepage. Only break the rules if you have a good reason for doing so. Don't alienate your users. I definitely got lost in my slides, so that's exciting. Nope. Cool. Sorry. UI conventions, the same goes for accessibility. Ultimately, it's better to have a usable and accessible website than one that's really creative. But I believe that we can work within those constraints to build creative sites while still maintaining usability and accessibility. Much of design is driven by trends. Slavishly following those trends doesn't account for your project's needs. Design is about communicating a message from your client to your audience. If your audience can't distinguish between a hospital and a music festival, your meaning is lost and understanding is diminished. Visual patterns are a language. They have meaning. Think about what you're communicating. What's trendy isn't always going to be what's right for your project. All fields of design need innovation to drive forward, and the web is no exception. Web design desperately needs new ideas and thought leaders. We need to buck trends in order to make new ones. Now, it's all well and good saying be different, be unique, buck trends, be a special snowflake, but how do we actually do that? How do we design websites that don't look like every other website out there while still accounting for current UI conventions and modern tastes? I have some ideas. First of all, not everything needs to be totally flat. I expect we'll move away from flat design at some point anyway. Design and trends tend to be cyclical, but flat design is going to look as dated as those swooshy logos in a couple of years. So try playing with texture and pattern. When used well, they can add dimension and visual interest to our design work. As human beings, we respond to natural organic objects. It's why we feel an emotional connection to hardwood floors, but not so much to steel girders or glass windows. These subtle imperfections humanize what can otherwise be a very sterile interface. For the same reason hand-drawn elements are effective, particularly if you want to impart an emotional reaction in your audience. Play around with typography as well.  It's beautiful, but it's really overused. And beware of distinct but commonly used typefaces. Some Google fonts can fall into this trap. Lobsters one, play fairs another. It's beautiful. It's one of my favorite typefaces, but I've seen it used for corporate sites. And it doesn't fit. Think about your message and choose something that suits. Take inspiration from classic typography. Try unusual combinations. Instead of using a song for everything, try serifs or slab serifs. You can get really crazy and use a script or a display face for headings only. You can get really creative with typography these days. Try using oversized type, or type that's broken out of the box. This can add interest even if you're using a plain or typeface. Blowing type up really big makes it become an illustrative element. Drop caps work on the same principle, but it's really easier and easier to do them in CSS. There's a property called initial letter that is getting more and more browser support and allows for really fine grained control over a drop cap. Try getting creative with your layout to avoid that boxy syndrome. The concept of breaking the grid is very traditional to print design, but we don't really do it on the web very much. If you're not familiar with the concept, read making and breaking the grid, which talks about building grids and then breaking them. The basic concept is that you want to align every element on your page to an underlining grid so it's nice and orderly and feels well-structured. You can then pull an element outside of that grid. This gives it more visual weight and adds dynamic tension to your page so it's more interesting to look at. You can also try working with non-boxy shapes. You can break your text around objects. We have more tools to play with now. We can use Flexbox or CSS columns. We can skew and rotate elements. We can use SVG clipping masks. Even something relatively simple like using a squiggle shape instead of an underline or using multiple borders around an image can add character and visual interest to a layout that's structurally otherwise the exact same as every other website. Animation is also a great way to add visual interest. Again, these tools have been improving and expanding. We can do a lot of animation with CSS alone these days. We don't even need to learn JavaScript. This site does a lot of... It's not going to move because it's a PDF. But in theory, this site would have been animating and it would have looked really great. It's very easy to go overboard. When this site moves, it actually animates every single element as you scroll down. As you scroll down, they start popping out at you and things jump out and they move. It's absolutely madness to look at. It's really easy to go overboard. So as a general rule, try to animate elements that are interactive and animate on the interaction rather than on the scroll. All fields of design need innovators and the web is no exception. So get outside your comfort zone, interact with design in a new way and bring that passion and learning back to your web work. One of the neatest things and the things I love most about design is that it's everywhere. It's an airport signage, it's in packaging, on billboards, on restaurant menus. You cannot possibly escape it. So go ahead and experience it. Viewing design through a wider lens will improve your work and bring you new ideas. Look at packaging design or hand lettering where typography and illustration converge. Read fashion magazines. Photography and colour can be amazing. Look at film titles, both modern and new. They're a great source of inspiration for animation. This is a theme on WordPress.com. It's super old, it's not responsive, but the sort of soul Basi style means that it does some interesting stuff which makes it look different and interesting. Look at interior design. There's lots of pattern and textile inspiration that can be found here. Magazines are a great source of layout and breaking the grid.  Not just art and design museums, but also science museums, history museums. Displays are a great way to understand interactive design. Experiencing design in the real world and interacting with it is a great experience. Read print media. Book covers are a great source of inspiration for illustration and conceptual thinking. There are so many things to expire you out there. Embrace a multidisciplinary approach to design. Don't just look to the web for inspiration. This is a vicious cycle that means everything keeps looking the same. Look outside the web for more inspiration. Once you're inspired, experiment. Try taking a magazine layout and recreating it in CSS as an exercise to learn new tools. Try your hand at calligraphy or hand lettering. Make furniture, paint stuff. Make time for creative play, even if it's only a few minutes a week, and not just with code, but also with other disciplines. Experimentation is how we discover new things. Bucking trends is how we make new trends. So take risks. Don't be afraid to make mistakes. You can make the web more diverse, and more interesting. So go out and experiment. Thank you. Is this on? Yeah, there we go. We've got some time for questions. We've got a couple of mic runners in the middle there. So if you want to ask Sarah a question, then please raise your hand, and we'll get a mic to you. Oh, have you got it, Matthew? Anyone? It's how I look at the front there. What have you been inspired by lately? Great question that I don't have an answer for. Clearly that's a sign I need to go out and experience more design in the real world myself. Any of this? Hello. Do you have any sort of thoughts on what you think is next in terms of web design from what you're thinking about or what you see is going on at the moment? So I've been starting to see more skewed lines, which is a start. It's a sort of a small step, but it's a start. So oftentimes when things used to be like very straight lines, sometimes people are now using skew to actually move that. So I think that's the first step, and I'm starting to see that crop up a bit more now. Really good to talk. I have a question about where do you keep the, in a sense, the line, the boundary between experimenting and keeping the interface usable? Could you maybe elaborate a little more on that? Well, I think it's worth considering your audience there. If you're building something that is more experimental, experimental, you can push the boundary a bit more, but if you're building something that people need to use, you probably want to gear yourself more towards the sort of usability aspect. But testing is always a great way to find out if your experimentation will work or not. So I thoroughly recommend testing all your designs, even if it's just giving somebody in a coffee shop and seeing if they can use it. Any other questions? Nope. Thanks again, Sarah.


Welcome. This is Melissa Arma with the Stock Swoosh and I'm reviewing Urban. Urban was the Stock Swoosh Show player the day today. The only thing we liked and did and watched in the really only the good gap today and it worked. So you could be out of this. Some people got out of this early. I felt that it had a bigger drop in it. Actually let's take a look here at this market. So right now, let me go back and show you here what we did. Stock gap down. Close the night before up here at 1791. Opened in the morning here at 1730. Again, I get up in the morning I rate gaps and that's how I make the choices for longs and shorts. This was a short stock. We shorted it here. Got the drop. Rallied up. Added more in here. Got the drop. Again, some people got out here. Some people got out here. I really felt that it had a bigger move in it. I did say the possibility exists of 1630, 1625, 1660, I mean 1620 today. So this could get down another 35 cents, maybe 40 cents. And so if people are still in it, I think there was one person still in the room in it. That's perfectly fine. It's not backing up. It really is a nice short, especially if you did an ad. Very easy trade today. Very nice short today. Moved fast. Was up really quick and it's still going. You can ask for more. So good job everybody. If you're interested in the Golden Gap course email me at Melissa at thestockswish.com. Have a great day everyone.


Hello, I'm Sagar Asnani and I am a PhD candidate in musicology and medieval studies here at Berkeley. And my interest is in the kind of the intersection between language and music in medieval, basically what's now France. So the poem I've chosen to read today is called Tan Mabelis Lamourous Pessamen. The amorous thought delights me so. It's a medieval Occitan poem by a troubadour named Fouquet de Marseille. So they spoke Occitan, which is a language which actually is considered like an indigenous and endangered language because there's so few people who use it in their daily interactions today. But in the 12th century, in the southwest part of France and centered around like Toulouse, Poitiers, this language was actually really, really a prestige language. And it was spoken by some of the most powerful princes and dukes and counts and kings of France. Tan Mabelis Lamourous Pessamen says that it's a good thing to have a good heart. Because we can't have another piece of paper, no one likes it, no one likes it, so you know what I'm going to cook. If you love me, you'll never kill me. I promise to play with you for a long time, and I'll train you for a long time. The rhyme scheme here is essentially Occitan, right? And for the first line, Tan Mabelis Lamourous Pessamen. And Pessamen with that end S sound is very Occitan. If you go down to the fourth line, Ni mais, ne gousse, nomes douce, ni placence. And so there you have the same word placence, which rhymes with Pessamen, right? Ence is the rhyme scheme here. If this was French, plaisance. And so you would actually have that S sound at the end of plaisance in French, but then it would rhyme with Pensement. Features of this that are distinctly Occitan are woven right into the very lyrics themselves. So what's really interesting is that the same text, even though it might be very musical in one language, the moment you translate it, it loses a bit of that musicality because when we're translating, we're translating for meaning, not for sound. If you know the BTS butter, right? Smooth like butter, like a criminal undercover. That's not a play on English of really the words of what they mean. It's a play on English for how they sound. But I don't think they really cared if it was smooth like butter or smooth like margarine, right? You know, that's not the central aspect of that song. So while translation is always like interested in bringing the most out of the meaning, out of the semantics of the music, of the poetry, I think that, you know, music has to deal with the sound of language.


Okay, so welcome to my session about GRAW-EM and its support for tools. I work on for Oracle Labs and on the debugger support in GRAW-EM. The following is for informational purposes only. You should not make any decision on this. So first I will talk about GRAW-EM and polyglot world that is associated with that. I will explain Truffle ISD interpreter which is an essential part of GRAW-EM for languages. Then I will describe instrumentation for tools, how tools can plug into GRAW-EM. And we'll then have some demos where I will show how GRAW-EM works and how the tooling look like. So GRAW-EM consists of several components. The core components of GRAW-EM is just-in-time compiler which is an advanced, very efficient compiler that replaces C2 in JDK. Then it contains a Truffle framework which is an interpretation framework for ASTs. Language are written as AST interpreters and they provide the AST nodes to the Truffle framework where they are efficiently partial evaluated and compiled. GRAW-EM provides by default JavaScript integration at LLVM. It's a bit code interpreter but you can install other languages as well like R, Ruby and Python. The next component for GRAW-EM is SDK API. It's for embedders. If you would like to embed GRAW-EM into your existing application, you would use the SDK API that will allow to work with GRAW-EM and run guest code on it, etc. Then it contains Oracle JVM runtime which adds Java libraries and garbage collector and things like that. And one part of GRAW-EM is head-of-time compiler. It's a native image generator which lets you compile bytecode to a native image so you can create a native application from your Java application. The advantage is that it's possible to compile also language interpreters. That means that you can create a native runtime that will execute JavaScript sources or other language sources or all these combined. Here is in the picture what I was talking about. You have a just-in-time compiler that compiles the languages that compiles to bytecode like Java, Scala, Kotlin.  All that is processed by GRAW-EM, JIT compiler. And it's possible to embed all of that into OpenJDK for instance where you can replace the C2 with GRAW-EM JIT compiler. And we also provide note implementation where V8 is replaced by GRAW-EM that allows you to run all the other languages in a note as well. We are adding GRAW-EM into Oracle database. It's possible to add it into MySQL or it can be run as a standalone application. Now what Truffle interpreter is, order language implementations are written as ASD interpreters. That means that there is a unified ASD representation in Truffle notes and all you need to provide a language integration is to write an interpreter that will translate the language source into the Truffle ASD. Then Truffle cares about the specialization of notes, partial evaluation and compilation. That all has the advantage that there is a very low overhead in language interpretation because the ASD representation is the same for all languages. That means that you can seamlessly execute one language from the other as the ASD is just one for all of them. Also, there is an instrumentation support built into the Truffle and it works on the ASD level. That means that when you install an instrument it plugs into the ASD and it can be specialized and partial evaluated with the code. So the instrumentation essentially becomes part of the code and that means that there is nearly zero instrumentation overhead because it's all compiled together. And tools are attached as node wrappers to the ASD. Again, here we see that in the picture. Initially, you will have ASD nodes initialized. Then depending on data that are flowing through these nodes, the nodes get specialized for strings, for double integer at whatever types are there or there is some generic representation. After that, it stabilizes the Truffle, creates the specialized nodes and then it's partial evaluated and compiled altogether. How tools are plugged into that is here. Consider a node. The node is replaced by a so-called wrapper node that delegates to the original node and also to a probe node. That is something which can be used to attach the instruments. Here are several subscription nodes attached to that probe and that delegates to client nodes that are provided by the instrumentation, by the tool that you want to plug in. So for instance, if you have a debugger and you submit a breakpoint, you find the correct node which represents that part of the code and you create a node that represents the breakpoint. The breakpoint gets the notification when the node is started to be executed. Also, when the execution of that node finished, it gets the return value or when an exception was thrown from the node execution, it intercepts the exception as well. This, for instance, allows to have very fast conditional breakpoints because the condition can be part of the AST and it's executed together with the code so there is near zero overhead for the condition execution. The important thing for Gravium tools is that they are language agnostic. They attach to the Truffle AST and they should not care about the particular language that the node came from. How it finds out where it actually should attach or what the nodes are about when it cannot find language? Nodes have tags. When a node represents a function, it's tagged with a root tag. When the node represents a statement in the language, we have a statement tag for that and similarly for calls, for expressions, etc. So this is how tools find out what the node represents. Then nodes have a source section information associated. The source file it came from and line and column number information. So again when you're going to submit a breakpoint to some line in some source file you find that from this node information. And this is always language agnostic. So when instruments decide where to register it needs to define which tag and which source section it should attach to. This is declared in advance and when the node is created the instrument is notified about that and the wrapper node is created around that node and the instrumentation is attached. So in order to see how it works I'll show you some demo. We start with cross language debugging in Chrome. So I have prepared a few files in JavaScript, in Python, in R, and in Ruby. We can run all of that in a Gravium. I'll show you the run script. We'll use Gravium RC11 and we run a node with inspect when we will breakpoint at the first execution. We'll attach Chrome to that in order to can use Chrome inspect and here we'll see Gravium is available to attach. Do you see that? So we are suspended to the first statement here. It's called to a weather method. This is a very simple sample application that computes weather regression model from some cities. We have a database of cities and temperature of them. It's some artificial database and you are going to create a regression model out of that. It started from node. It's a JavaScript application but to compute a regression model it's not very convenient to do that in JavaScript so we are using R for that. So we submit a breakpoint where the model is created. Maybe first I can show you that this JavaScript file is loading. If we step into that, it's loading Ruby file. It's loading also R file and there is some Python file written here as a string. So we can continue to that breakpoint where the model is actually computed. It takes some time to load the model and initialize the languages and so forth. And when the breakpoint is hit, we can step into that and we are in an R source. Here you can see on the costech that I came from JavaScript and the JavaScript just calls the R function written here. If you look at the arguments, it gets some functions which came actually from JavaScript which called this R function. So we can step through some R code for a while and eventually we'll get into the place where the JavaScript function is going to be executed. When we step into that, we are back in the JavaScript and we see on the costech that from the JavaScript R was created and R was executed and that called the JavaScript again. So the costech shows you all the stack of the languages. We can go back to R. Here you can see the local variables. So Chrome Inspector has fortunately no problem to show you R variables here. And if we get back to the JavaScript, we see the return value here. It's an R list which is essentially an array, but it came from R and R list. So JavaScript here gets some value from R, but it knows from the generic representation that it's an array. So it had no problem to find out the length of that R list because it's an array. It knows that it has some size and JavaScript knows that the length is a property of array and it shows you return the size of that array. In a similar way, we can step into other languages. We have Ruby here, so we can step into Ruby. Again, we can debug the Ruby here in the Chrome Inspector. So no matter of what language is there, the tool is able to work with that. Here we can step into the Python script and again debug a Python script including local variables and everything. When we are back here in the JavaScript file, we can look to the local variables. So for instance, here we see a function which came from Python and which has the Python description. We have a weather model from Ruby. We have cities from Java, city service Java object here and there is a create model function from R. So we have all languages here available, all languages interpreting and you can debug all of them at one place. So that's all from Chrome Inspector. The next demo is going to be some preliminary implementation of LSP. We have a preliminary integration with Visual Studio Code. So I will start an LSP server here. So you're starting now with VM with SNLSP server component. Is that correct? Yeah, this is an LSP instrumentation which is soon going to be a part of GraVM. Currently it's in an experimental version and it's provided for a so-called simple language. We have a testing language for GraVM so that we do not need to deal with all the complexities of other languages but this is something to test to Swiss and to showcase how GraVM works. So at least you are sure that there are no existing language servers for this simple language. It's served by this GraVL LSP server and now I will go to the VS Code client and run a sample application in Visual Studio Code. We'll run this LSP client here, the LSP client plugin. And it should open, yeah. Here it opens a sample SL file. It's written in the simple language and it has connection to the LSP server. So for instance if you select some variable name it finds all the locations or places when the variable is read and when it's written to. This is provided by the language. The notes are marked as that they are writing some variable or they are reading some variable and from that the LSP integration finds out locations of variables and if they are read or written to. There is also code completion so you can see the local variables and the other things that you can call at that location. So this is a preliminary version of the LSP server. And the file name demo is in NetBeans. Yeah, NetBeans GraVM integration. Here I have NetBeans 10. It's the latest version that was released late in the December last year. And it has a built-in support for GraVM debugging. So I will run the demo that you already saw. It's here. But this time I will not run it with the Chrome Inspector option but with standard debugging options. And so it's listed on the address 8000. I will attach Java debugger to that. And yeah, it does something. In order to see what it does, we pause that. Here in the main thread you can see that it's doing something with Trefunals so it's executing something on the GraVM. And for GraVM debugging we have a special icon here that is relatively new that's a toggle pulse in GraVM script. That means when you toggle that it will suspend as soon as it finds out that some script is executing in GraVM. So we can continue the execution and wait for this action to actually find this out. And we are at the beginning when R script is executed. Here on the stack we see the JavaScript file and we can do the very same debugging that you saw in Chrome Inspector here in NetBeans. Yeah, we can continue the breakpoint. We can step into an R function and here you see the local variables and everything. The advantage is that this is Java debugger. That means that you can switch from the script view to Java view. And here in the stack trace you will see all the notes that are executed and that actually interprets the language. That helps language implementers to see how the notes that were wrote were executed and that provides the insight into how Java works. And you can see here also the probe nodes, the tools integration. Here the probe node was entered and there is stepping node associated that comes from debugger. The node was entered so we get on-enter event. We can step and we will suspend it on a step. So that's all from me. If you have some questions, yeah, you are first. What is this expected way to learn TOEFL? Because I read everything on the GAU website and I still don't understand half of it. Because you need to read some random papers like TOEFL to understand how to start it inside. Do you want to write some comprehensive tutorial or something? We are still working on documentation. And unfortunately probably the best way how to start out is to look to the simple language implementation and just see how... It's simple, really. Yeah, yeah. Well, sort of, yes. Comparing to other language implementations, it's very simple. But we are working on the documentation definitely, yes. Okay, I can help you with this. Okay, you are welcome. Question about the Chrome demo was very interesting because I'm wondering how you can go all the different types from R, from JS, from... You actually had an icon with C++. How does all this look fine in the Chrome debugger which expects, I think, JavaScript? Yeah, fortunately it's quite tolerant because it also expects TypeScript or CoffeeScript or other other languages. So they apparently do not have anything specific to JavaScript but they will blow up if they get another language. So this is why we can do that. Dictionaries, Python dictionaries, they are very different. Yes. Ruby has the anchors, like the keys, they are actually... Yeah, every object from every language provides its two string implementations. So we take the string representation from the language, the language sees that object. But it's still language agnostic in terms of tooling. Yeah. But I understand correctly, the compiler is faster than the Java compiler, the just-in-time compiler. Are there any plans to improve the Java runtime to get as fast as...? There is a project to move actually the growl just-in-time compiler to open the decay. In many situations, yes, not in all of them but in probably the vast majority of cases it's faster. Yeah. This is sort of the plan, so we'll see how it works. Yep. In JavaScript, there are double... You should repeat the question. Yeah, so I'm sorry. The question was how we deal with types. For instance, in JavaScript, there are doubles but in Python, there are other types. JavaScript has big integers, so JavaScript can convert that to big integer. The idea is that there are some primitive types which flows freely through languages and there are object representations that when a language gets object from some foreign language, it delegates operations on these objects to that foreign language. So when it needs to find out a property of some object, it asks the object to give me that property and it's up to the Python code to search the object layout and to provide that property. So if that object doesn't represent a primitive value, if it's quite long, it can delegate all the operations on these values to some methods on that object and JavaScript delegates that to Python. Yeah, definitely. The languages need to be updated with the latest versions. So for instance, in JavaScript or in Node, when there are some new features added, we need to keep up with that. But it's not that hard because all that we need to upgrade is the interpreter, not the runtime or other things, just the interpreter and that's it. So that allows us to bring new JavaScript features faster than V8, for instance. There are some libraries distributed with the languages. For instance, in R, we have many libraries redistributed and regarding Python, I'm not really sure, but we definitely work with NumPy or have some integration with NumPy. So yeah, these languages are not in final state yet. JavaScript and LLVM is final. It's complete, but these other languages are in progress. They are mostly complete, but not 100%. Can you talk about the question and regenerate the tree? Let's say you modify a function now. Yeah, the question was when there is a probe, if it's possible to replace that when the code is modified. Yes, the instrument can freely attach and de-attach, and then we transfer back to the interpreter mode, change the notes layout, change the AST, and then after that stabilizes it's compiled again. So yeah, there is just the optimization at that location. The notes are changed as they need to be. For instance, if you remove a breakpoint, the breakpoint that represents the note is removed. The note structure changes. So it's transferred to interpreter mode, and then after it stabilizes, it's partial evaluated again and then compiled again.