@mn98 indeed you've been sheltered from js, that's how you write values to console :)
console.log(a). It's kind of the same as println(a) except that the latter forces a toStringwhich often gives not useful info for js objects. OTOH logging with console.log writes the object in such a way that you can expand and collapse it and so on in the browser console
@mn98 that translation you're doing, I suppose you're working with a javascript library that doesn't have typescript definitions? If that's the case it might be more worthwhile to contribute typescript typings to DefinitelyTyped, where a lot more people can use them and we can convert them to Scala later
interface A{a: number}
declare const aCtor: new (a: number) => A;
// A2 = A
type A2 = InstanceType<typeof aCtor>
so this is an advanced topic, for which we have nothing close to a translation in Scala. In the converter we can actually implement this for concrete cases (
InstanceType<MyClass>), but for generic cases (InstanceType<T>) I see no other solution than to output js.Any. It's not implemented because I've never seen it used
@oyvindberg thanks for the details, this is an especially advanced topic for me who only discovered
I'm playing around with GoJS basics and the react flavour, attempting to render all of this with Slinky. It looks like typescript definitions exist for both gojs and gojs-react. So far I've managed to get the canvas element (generated by GoJS) appearing in my html but no diagrams are rendering. If I manage to get the basic or 'hello world' diagrams working I'd be happy to add an example project to the existing ScalablyTyped collection.
Btw, it was the
console.log this week :-)I'm playing around with GoJS basics and the react flavour, attempting to render all of this with Slinky. It looks like typescript definitions exist for both gojs and gojs-react. So far I've managed to get the canvas element (generated by GoJS) appearing in my html but no diagrams are rendering. If I manage to get the basic or 'hello world' diagrams working I'd be happy to add an example project to the existing ScalablyTyped collection.
Btw, it was the
GraphObject.make functions that were returning InstanceType[T]. Instead, I'm instantiating the various diagrams/shapes/etc. and manipulating their properties directly, rather than using the make routines, which is also much easier to read.
Hello everyone, I'm having a little trouble with scalably on windows. I have a project with remote cache set up, and when I build a project on ubuntu I can see the cache being pulled correctly, but when I try to build the same project on windows I don't even see the message of it trying to pull from the remote cache. Has anyone seen anything like this?
@mn98 if you create a draft PR to https://github.com/ScalablyTyped/SlinkyDemos/ I'll help you make it work there
If you're willing to spend a little bit of time digging on your side and testing some snapshots I'll go ahead and add that debug output so we can get it fixed
Yeah, I'd be delighted to help. Just let me know what to do
@oyvindberg I pushed a skeleton demo for the GoJS "Hello World" diagram. Despite a clean compilation, I'm hitting a runtime error to do with the discovery of some of the GoJS types when running
gojs/start. Presumably I've missed something obvious there?
The error being:
[info] Bundling the application with its NPM dependencies
[error] ModuleNotFoundError: Module not found: Error: Can't resolve 'gojs-react/lib/types/components/Diagram'which seems a bit confusing because Diagram is in gojs, not gojs-react, but then again I'm not 100% sure how the js/react/ST/Slinky magic works.
@mn98 I pushed a commit now, to a branch with the same name in the parent repo, see ScalablyTyped/SlinkyDemos@3f9acc5
Error: Can't resolve 'gojs-react/lib/types/components/Diagram' is a result of using the tree shaking feature. I should probably label it as forever experimental and something which you can experiment with turning on after you have finished coding.
as for the rest, I'd say de-javascriptified code is so much easier to understand than the original example here https://gojs.net/latest/intro/react.html
@domaspoliakas:matrix.org I'll have a look tomorrow and let you know
@oyvindberg thanks very much! Those "tweaked" methods are interesting, must confess I'm not sure what's happening there.
I tried to address the 'todo' by adding this and following your pattern:
class ArchetypeData(val text: String, val color: String) extends go.ObjectData
...
diagram.toolManager.clickCreatingTool.archetypeNodeData = new ArchetypeData("new node", "lightblue")but that resulted in a JS runtime error upon double clicking in the demo diagram (screenshot above).
those tweaked methods (couldn't think of a better name, it was late :D) was just to account for a difference between typescript and scala. In Scala you cannot pass
js.Any where a String is expected, but in typescript you can pass any where string is expected
Run
stPublishCache again from somewhere, and then try to open the project on that windows machine. It's possible that it works now, and in that case great
if not, run these two commands in sbt
debug and stImport, on both the machine you published from and the machine you try to pull to. Then paste the output to a github issue or something like that
Gave the snapshot a shot, but it seems the issue persists
I'll try to reproduce on a smaller scale and get those debug logs
I have some autogenerated code from ST, that outputs this
@js.native
trait ColorAttrCallback extends StObject {
def apply(args: js.Any*): String = js.native
}which is a parameter to a function, since it has the js.native modifier I can't "new" it, any good ideas what people do in this scenario?
3 replies
Hello. Did a little bit of digging and I see that on windows the URL being requested is, for example
org.scalablytyped/google-libphonenumber_sjs1_2.13/7.4.20-5fe8c3/srcs/google-libphonenumber_sjs1_2.13-sources.jarWhereas when importing from ubuntu it is
org.scalablytyped/google-libphonenumber_sjs1_2.13/7.4.20-f8667e/jars/google-libphonenumber_sjs1_2.13.jarNote the different digest. I tried to read through the sources a little to see if I can find how it was generated, but got a little lost. Any clues?
@domaspoliakas:matrix.org Yeah, ensuring consistent digests across machines has not been possible yet, though within the same machine it is consistent. That's mostly enough. When the remote cache is enabled every puller will just get the digests computed by the machine which computed the artifacts in the first place, which is hopefully good enough.
so if you can get me those debug logs that would be the best :)
The thing about the logs is that I may need to do some purging of potentially confidential things from it, and there's a lot of logs so I was trying to avoid it 😅
Maybe I'll work some more on a reproduction repo instead
If there's a particular subsection of the logs that you need I can also get that right now
That is, I assume that once the phase 1 compiler stuff kicks in the rest is irrelevant?
Don't worry about it, I'll get it up to phase 1 compiler, that's not a lot of logs to run through. I should be able to do it later today and I'll open a github issue with it as you suggested
I opened an issue with the logs now. I also tried to work on the reproduction a little, but I ran into a different issue on that. When I do
stImport it seems to hang on fetching the cached run. The odd thing is that the cache settings are the same as on the main project that I opened the github issue about, and that project seems to be fine. The repro project is https://github.com/domaspoliakas/scalably-test
On that project, doing
submodule/stImport fetches from the cache correctly on ubuntu, but seems to hang on windows
and that project seems to be fine
I mean stImport complains about files not found, but does not hang