profile
viewpoint
James CrazyPython North Carolina, USA High school student and software engineer. I like dynamic typing, strong typing, and performance. My twitter is @CrazyDave2345

CrazyPython/atomsim 1

see if molecules are possible or not

CrazyPython/boinc-heroku 1

An old project I did to learn about Un*x - One-click deploy of BOINC on Heroku

avertly/tempora 0

The clean and beautiful timer app of the 21st century.

pull request commentdlang/dmd

Type: add mcache

Can someone explain for me, a beginner, what swcto means? A long explanation could reveal lots of interesting DMD internals. Maybe that could help spark the discussion on a better name.

WalterBright

comment created time in 2 hours

startedforeversd/forever

started time in 4 days

startedteam-video/aviary.sh

started time in 4 days

issue commentispras/llv8

Could LLV8 be rebased on upstream V8 changes?

How much information is lost by the lowering of JavaScript to Hydrogen?

I understand that Turbofan has an SSA-like sea of nodes representation. I also understand that LLVM is an SSA.

CrazyPython

comment created time in 5 days

startedsam46/Agar.io-Clone

started time in 5 days

startedhonkit/honkit

started time in 7 days

startedmceSystems/node-jsc

started time in 7 days

startedmozilla-spidermonkey/jsparagus

started time in 8 days

issue commentispras/llv8

Could LLV8 be rebased on upstream V8 changes?

Furthermore, for a CPU-intensive JavaScript application, how much better could LLV8 do over TurboFan?

CrazyPython

comment created time in 8 days

issue openedispras/llv8

Could LLV8 be rebased on upstream V8 changes?

I see LLV8 has modified Crankshaft. Upstream, V8 has removed Crankshaft.

How feasible (how much time) would it be to rebase V8 on upstream changes? Does LLV8 depend on CrankShaft?

created time in 8 days

issue commentgpuweb/gpuweb

C-like declaration order

The builtin and location assignment are different in WGSL. Variable declarations are different. How arrays, and pointers are declared is different. Loops are different. How your workgroup size is specified for a compute shader is different.

That can be handled using #ifdef sections. Still, the core matrix transform logic is the same across all compilation targets.

litherum

comment created time in 8 days

issue commentgpuweb/gpuweb

C-like declaration order

People expect web applications to boot quickly. Remember that when suggesting application developers ship shader compilers in the browser.

litherum

comment created time in 8 days

issue commentgpuweb/gpuweb

Use a traditional C-like syntax for WGSL

I'm curious why you don't include Rust as having traditional syntax.

Python's syntax had types bolted on. So did TypeScript and Flow. Rust inherited its syntax from TypeScript and Python.

FORTRAN, the oldest language still in use today: integer :: i;

 function func(i) result(j)
    integer, intent(in) :: i ! input
    integer             :: j ! output
    j = i**2 + i**3
 end function func

All versions of C: int i;

int func(int i) {
    return j;
}

The ! syntax for templates is very D-lang specific and nearly resembles line-noise imo.

The type argument to the "templated type" is part of the meaning of the type as a whole. You can imagine the "!" as part of the identifier name. For example, vec4!int and vec4!f32 are used for completely different purposes, and the "int" and "f32" parts distinguish them. < and > scream "THIS IS A GENERIC", while "!" let's the type argument take front position.

CrazyPython

comment created time in 8 days

startedtc39/proposal-record-tuple

started time in 9 days

issue commentgpuweb/gpuweb

C-like declaration order

#888

litherum

comment created time in 9 days

issue commentgpuweb/gpuweb

[wgsl] Reasoning behind inheriting rust-like syntax

In the initial idea there was the slight goal to get the syntax for types closer to Typescript (essentially a typed Javascript) to improve the familiarity for Web developers. That's why there is thevar name : type style. The syntax for function was indeed inspired from Rust.

#888 While the idea of helping JavaScript developers use WGSL is attractive, doing this simultaneously hurts their ability to transition into other systems languages such as C and C++.

Yen

comment created time in 9 days

issue commentgpuweb/gpuweb

vec4<f32> is too hard to type on the keyboard

I propose the syntax vec4!f32. The arguments after the ! are equivalent to what's inside < and >. Parentheses are optional for one argument. For arrays, it would be array!(int, 4). This also has the advantage of being easier to parse.

litherum

comment created time in 9 days

issue openedgpuweb/gpuweb

Use a traditional C-like syntax for WGSL

Hi,

For context, I am a developer whose first language is Python (I co-authored a Python library with hundreds of stars) and currently works on a JavaScript game that is remixed by children to teach them JavaScript. In other words, I am an educator of computer science tied to the web platform.

Using a more traditional C-like syntax will help JavaScript developers learn the C-like syntax, which will help them move towards C/D/C++. This will help them expand their horizons quickly.

For languages where types are mandatory, the Rust/Python-ish syntax only increases typing. Typing is often a barrier for children and teenagers that are learning to code.

[[location 0]] var<out> gl_FragColor : vec4<f32>;
fn main() -> void {
    gl_FragColor = vec4<f32>(0.4, 0.4, 0.8, 1.0);
    return;
}
entry_point fragment = main;
@location!0 @var!out vec4!f32 gl_FragColor;
void main() {
    gl_FragColor = vec4!f32(0.4, 0.4, 0.8, 1.0);
    return;
}
entry_point fragment = main;

The latter example is 13 characters shorter.

By being too soft and forcing developers to learn a trendier syntax, it will make people learning to code to take a farther route in the long-term. While in the short-term the Rust/Python-like syntax will help people learn WebGPU quickly-- more familiar to users of TypeScript and Python-- it will harm their ability to learn languages with more traditional syntax, such as Swift, C, D, C++, and many more. The aforementioned languages are clear examples of stepping into system programming. Systems programming should be for everyone.

created time in 9 days

startedobfuscator-llvm/obfuscator

started time in 12 days

startedopengaming/osgameclones

started time in 15 days

startedbengott/fish-school

started time in 15 days

startednode-ffi/node-ffi

started time in 16 days

startedgameclosure/webgl-2d

started time in 18 days

startedmemononen/nanovg

started time in 19 days

startedxFAANG/askql

started time in 20 days

startedAshleyScirra/via.js

started time in 21 days

startedegret-labs/egret-core

started time in 22 days

startedlayabox/LayaAir

started time in 22 days

startedgoogle/caja

started time in 24 days

startedrpetrich/swift-to-js

started time in 24 days

startedhuntlabs/hunt-framework

started time in 24 days

startedtmikov/jscomp

started time in 24 days

pull request commentdlang/DIPs

Dynamic Size Static Arrays 2

Imagine a simple implementation of dynamic-size static array: each call to a function that uses dynamic-size static array gets its own area of contiguous uninitialized memory. (It would be implemented by allocating a single page with a single syscall or returning a page from a per-thread pool of unused pages and lazily allocating new pages for the later parts of the contiguous section.)

This works very well if no references to the array escape the lifetime of a function. If one does, we must either copy data out or break the "always allocate at the start of a region."

If a program allocates a dynamic-size static array in-place and then returns it, most compilers would produce a copy, because static arrays are value types and the storage is inline. Copies are expensive.

The idiomatic D solution to this is to pass an out parameter. This artificial separation between returning large value types and writing them to an out parameter seems to be a language smell to me.

CrazyPython

comment created time in 24 days

Pull request review commentdlang/DIPs

Dynamic Size Static Arrays 2

+# Dynamic-size static arrays for D+| Field           | Value                                                           |+|-----------------|-----------------------------------------------------------------|+| DIP:            | (number/id -- assigned by DIP Manager)                          |+| Review Count:   | 0 (edited by DIP Manager)                                       |+| Author:         | James Lu (jamtlu@gmail.com)                                     |+| Status:         | Draft                                                           |++## Abstract+Often, it is necessary to allocate a data structure on the stack based on a+size known at runtime. This proposal suggests adding dynamic-size static arrays,+which are destroyed when they go out of scope. Dynamic-size static arrays and+slices of them may be passed up the stack. The syntax is designed to encourage+function signatures to use slices as much as possible, in contrast to the C+convention of passing an array length and then a VLA. The overall goal is to+help evolve D into a fewer-GC language.++## Contents+* [Rationale](#rationale)+* [Prior Work](#prior-work)+* [Description](#description)+* [Copyright & License](#copyright--license)+* [Reviews](#reviews)++## Rationale+`@nogc` programming is useful in many contexts. For example, currently WASM+does not have a garbage collector, limiting D applications to `-betterC`+mode. ++It is often important to be able to quickly write `@nogc` code for+performance-critical paths. After identifying hot functions using a profile,+one should be able to alter a dynamic array that is only used within a single+function to be allocated and deallocated automatically with `@nogc`.++What is missing is an ergonomic way to dynamically allocate a static array on+the stack built-in to D. You can take slices of static array as parameters++```dlang+/** A well-known algorithm for finding the topological sorting of a (possibly+cyclic) directed graph. It deletes edges from its input as it runs, meaning+adjacency_list is modified from within the function body.++Because dynamic-size static arrays are value types, even when the function body+modifies adjacency_list, the caller does not see the modifications.+*/+@nogc auto kahnsAlgorithm(int[][?] adjacency_list);+```++## Prior Work+* `alloca`+* `malloc` and `scope(exit) free`+* Wait for D to support more C++ headers or use Calypso+* Just use C++ +#### Use a dynamic array and copy the contents+#### Templated code+Make this legal:+```dlang+@nogc void example(N)(int[][N] adjacency_list) {+return N;+}+unittest {+int[][100] array;+assert(example(array) == 100);+}+```+Templated code is an alternative to having to hardcode the size into a function+while keeping it `@nogc`. However, this would not work for arrays whose maximum+size is unknown at runtime. ++#### Copy parameters+```dlang+@nogc auto bfs(copy int[][] adjacency_list);+```+*Background:* It is already legal to receive a dynamic array in `@nogc` code.++The `copy` parameter attribute creates a deep copy of the function parameter.+In this case, the parameter `adjacency_list` is a static array of dynamic+arrays. ++When passing in a copy parameter, a copy is created at the entrance to the+function body. Copy parameters are always implicitly `const copy`, since to the+external caller, the passed in parameter is never modified.++#### `scope T[]`+Compared to scoped dynamic arrays, dynamic-size static arrays can be passed in+by value. Unlike, dynamic-size static arrays, scoped dynamic arrays are+primarily useful for initializing a data store to be used within a single+function. ++## Description+An array declared with the form:+```+int[expr] array;+```+where `expr` uses information not available to CTFE, creates a dynamic-size+static array.++Dynamic-size static arrays may be freely shrunk and expanded. They own the data+they refer to. When a dynamic-size static array goes out of scope, the destructor+is automatically called. It is safe to pass a dynamic-size static array up the+stack. Like static arrays, dynamic-size static arrays may be implicitly cast to+slices.

Perhaps resizing should not be allowed. thoughts?

CrazyPython

comment created time in 24 days

startedalangpierce/sucrase

started time in a month

pull request commentdlang/DIPs

Dynamic Size Static Arrays 2

Ideas for arrays with size fixed on initialization:

  • A standard library solution in Phobos. There are currently many standard libraries for dynamic size arrays. including ones by Symmetry Investments and DUB.
  • scope int[]
  • Variably modified types (dependent types) and compiler representations for them to enable optimization
  • Language support for allocating dynamic arrays if Ownership and Borrowing checks pass in @live
CrazyPython

comment created time in a month

startedmindspore-ai/mindspore

started time in a month

PR closed dlang/DIPs

Dynamic Size Static Arrays 2
+167 -0

7 comments

1 changed file

CrazyPython

pr closed time in a month

pull request commentdlang/DIPs

Dynamic Size Static Arrays 2

Courteously closing out of no interest. Maybe some other day.

CrazyPython

comment created time in a month

issue openedGitSquared/edex-ui

Make the globe map work with actual data

<!-- This template is made to facilitate communication between you and the developer(s) of this project, and to get a better picture of what you are expecting. You are free to ignore it, but are encouraged to complete it.

We've seen lots of feature requests on this project, some were perhaps too ambitious, and some were implemented & shipped overnight. Don't be afraid to propose your ideas either way, every one of them is considered and you will typically receive feedback within 72 hours. -->

Perceived idea awesomeness

  • [ ] Wow, you don't have this yet???
  • [x] Would be super cool.
  • [ ] I'm not sure a lot of people would use it, but I'd love to have it.
  • [ ] Kind of a gadget, honestly, but why not?

Perceived idea difficulty

  • [ ] Quit your job first.
  • [ ] Would need some work, but nothing impossible.
  • [ ] Shouldn't be too hard to make.
  • [ ] Like, I could do it.

The ability to aggregate some sort of log file from each connected server and show it on the world map. Line-by-line JSON format in, aggregated onto the edex-ui map. This would help me monitor my service around the world and monitor bot activity / IDS output.

I'm not sure the most unix-y way way to handle a "side" tty for global/graphical output. It should be line-by-line so pipes can be used. Perhaps the world map is a function of a local file's contents.

created time in a month

startedGitSquared/edex-ui

started time in a month

startedcowrie/cowrie

started time in a month

startedsan-kumar/howdoi

started time in a month

startedcdr/code-server

started time in 2 months

startedflotwig/the-one-cert

started time in 2 months

startedthlorenz/deoptigate

started time in 2 months

startedtc39/proposal-explicit-resource-management

started time in 2 months

startedbenedekrozemberczki/littleballoffur

started time in 2 months

startedskypjack/entt

started time in 2 months

startedhauntsaninja/pyp

started time in 2 months

startedlibmir/mir-algorithm

started time in 2 months

startedzsdonghao/text-to-image

started time in 2 months

issue commentldc-developers/ldc

This code creates an error in llvm::CastInst::CastInst

Maybe it's a specification bug. Are class-to-associative-array casts well-defined per the D specification? I'm not sure what the correct behavior is myself.

The following code compiles and runs successfully in DMD:

interface Empty {}
alias map = Empty[string];
auto fn(Empty self) {
    auto dict = cast(map)self;
}
class T: Empty {}
void main() {
   fn(new T);
}
CrazyPython

comment created time in 3 months

issue openedldc-developers/ldc

This code creates an error in llvm::CastInst::CastInst

interface Empty {}
alias map = Empty[string];
auto fn(Empty self) {
    auto dict = cast(map)self;
}
0  ldc2                     0x00000001090136a6 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  ldc2                     0x0000000109013af8 SignalHandler(int) + 180
2  libsystem_platform.dylib 0x00007fff72900b5d _sigtramp + 29
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 18446603338594120896
4  ldc2                     0x0000000108de2389 llvm::CastInst::CastInst(llvm::Type*, unsigned int, llvm::Value*, llvm::Twine const&, llvm::Instruction*) + 21
5  ldc2                     0x0000000108de0e71 llvm::CastInst::Create(llvm::Instruction::CastOps, llvm::Value*, llvm::Type*, llvm::Twine const&, llvm::Instruction*) + 573
6  ldc2                     0x0000000108967eee llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>::CreateCast(llvm::Instruction::CastOps, llvm::Value*, llvm::Type*, llvm::Twine const&) + 62
7  ldc2                     0x00000001076979bf DtoDynamicCastInterface(Loc&, DValue*, Type*) + 196
8  ldc2                     0x000000010769780f DtoCastClass(Loc&, DValue*, Type*) + 1430
9  ldc2                     0x00000001076b2e24 DtoCast(Loc&, DValue*, Type*) + 760
10 ldc2                     0x00000001076ec058 ToElemVisitor::visit(CastExp*) + 184
11 ldc2                     0x00000001076e812d toElem(Expression*) + 105
12 ldc2                     0x00000001076ef0cd ToElemVisitor::visit(AssignExp*) + 753
13 ldc2                     0x00000001076e812d toElem(Expression*) + 105
14 ldc2                     0x00000001076b4d32 DtoVarDeclaration(VarDeclaration*) + 665
15 ldc2                     0x00000001076b4fc7 DtoDeclarationExp(Dsymbol*) + 275
16 ldc2                     0x00000001076e91fc ToElemVisitor::visit(DeclarationExp*) + 146
17 ldc2                     0x00000001076e8349 toElemDtor(Expression*) + 105
18 ldc2                     0x00000001076df403 ToIRVisitor::visit(ExpStatement*) + 195
19 ldc2                     0x00000001076df4eb ToIRVisitor::visit(CompoundStatement*) + 153
20 ldc2                     0x00000001076da887 Statement_toIR(Statement*, IRState*) + 39
21 ldc2                     0x00000001076ad069 DtoDefineFunction(FuncDeclaration*, bool) + 4547
22 ldc2                     0x000000010769b10e Declaration_codegen(Dsymbol*) + 46
23 ldc2                     0x00000001076bb736 codegenModule(IRState*, Module*) + 2417
24 ldc2                     0x000000010771e7ff ldc::CodeGenerator::emit(Module*) + 193
25 ldc2                     0x000000010773346d codegenModules(Array<Module*>&) + 223
26 ldc2                     0x000000010750d9d1 mars_mainBody(Param&, Array<char const*>&, Array<char const*>&) + 6353
Segmentation fault: 11

created time in 3 months

startedqubole/afctl

started time in 3 months

more