MegaApuTurkUltra wrote:

liam48D wrote:

yes yes thanks for crediting me for finding that domain thanks your welcome

HEY EVERYONE LIAM48D FOUND THE DOMAIN


…sorry xD

Jonathan50 wrote:

No archives!

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

technoboy10 wrote:

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

Snaaaaaaaaaaaap

MegaApuTurkUltra wrote:

technoboy10 wrote:

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

Snaaaaaaaaaaaap

We need a snap –> scratch compiler theeeeeeeeeeeeeeeeeeen

comp09 wrote:

MegaApuTurkUltra wrote:

technoboy10 wrote:

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

Snaaaaaaaaaaaap

We need a snap –> scratch compiler theeeeeeeeeeeeeeeeeeen

Someone please make one.

MegaApuTurkUltra wrote:

technoboy10 wrote:

ChocolatePi wrote:

At first glance I thought you meant they were working on classes (OOP) but I was disappointed.

Snaaaaaaaaaaaap

We need a snap –> scratch compiler theeeeeeeeeeeeeeeeeeen

MegaApuTurkUltra wrote:

Well if I could make an efficient system for storing object trees or calling code blocks by reference (no, broadcasting is too slow) I might do something.

comp09 wrote:

MegaApuTurkUltra wrote:

Well if I could make an efficient system for storing object trees or calling code blocks by reference (no, broadcasting is too slow) I might do something.

Why not just convert it to a bytecode and a Scratch implementation of a VM? That would work for C(++) –> Scratch and this as well.

• Hashtables in Scratch are annoying and slow. If you ditch reflection then you could convert every symbol into a unique identifier at compile time which would determine its position in the “heap” list. You could also have a stack for local variables, which you convert to stack indices at compile time. However tracking stack indices will get annoying, especially if you need to compile something complex.
  
• Splice is slow. To make sure GC isn't interrupted by any code that will screw itself up if the heap is half-modified it needs to run fast (<0.5 secs I think) so I'm thinking just mark clear sections in a separate list as overwritable. Always expand the heap as necessary but don't delete from it (because splice is slow). Pros: references to heap objects will always be static, easy to manage Cons: Complicated to implement; if the heap grows giant then it will crash the whole thing (if the heap gets fragmented and you start allocating a bunch of giant objects then your project is dead in the water)
  
• You can't call custom blocks by reference (like you can with broadcasts) so I guess reflection is pretty much out the window. Broadcasts called in no screen refresh lag a lot for some reason so custom blocks are the only way to have methods
  
• How the heck will a custom block call itself on another object instance? For example: if you have some class definition with method xyz, you create 2 instances of the class A and B, then what if A.xyz wants to call B.xyz when they're the same custom block in Scratch? Things get confusing.
  

MegaApuTurkUltra wrote:

Here are the current obstacles

• Hashtables in Scratch are annoying and slow. If you ditch reflection then you could convert every symbol into a unique identifier at compile time which would determine its position in the “heap” list. You could also have a stack for local variables, which you convert to stack indices at compile time. However tracking stack indices will get annoying, especially if you need to compile something complex.
  
• Splice is slow. To make sure GC isn't interrupted by any code that will screw itself up if the heap is half-modified it needs to run fast (<0.5 secs I think) so I'm thinking just mark clear sections in a separate list as overwritable. Always expand the heap as necessary but don't delete from it (because splice is slow). Pros: references to heap objects will always be static, easy to manage Cons: Complicated to implement; if the heap grows giant then it will crash the whole thing (if the heap gets fragmented and you start allocating a bunch of giant objects then your project is dead in the water)
  
• You can't call custom blocks by reference (like you can with broadcasts) so I guess reflection is pretty much out the window. Broadcasts called in no screen refresh lag a lot for some reason so custom blocks are the only way to have methods
  
• How the heck will a custom block call itself on another object instance? For example: if you have some class definition with method xyz, you create 2 instances of the class A and B, then what if A.xyz wants to call B.xyz when they're the same custom block in Scratch? Things get confusing.
  

ChocolatePi wrote:

I'm trying out making a Scratchin8r, but don't expect anything to come out of it

Rumanti wrote:

I have more sweet proof that this feature is coming. Us translators are made to not only translate current features, but it seems, upcoming features and guess what..? Things that seems to belong in the admin panel!



Ooh, and this too:



I would wager that if you ethically, carefully loop through the strings at translate.scratch.mit.edu, you'll find something.

WooHooBoy wrote:

can you access any of the other files?

Rumanti wrote:

WooHooBoy wrote:

can you access any of the other files?

You can look at them yourselves. You just have to be a translator to edit it; to see you don't need to.
http://translate.scratch.mit.edu/id/django-ui

Examples of phrases that I believe to belong in the admin panel:
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896768
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896706
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896392

Some strings are just plain mysterious:
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896208
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896699
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#unit=896189

And here are some strings that really hinted the existance of this feature, called “classes/teachers”:
http://translate.scratch.mit.edu/id/django-ui/translate/django.po#search=class&sfields=source

ghhg67754 wrote:

site not working

Jonathan50 wrote:

No archives!