arXiv subjects

Xinyue Feng

Publications and source records attributed to Xinyue Feng.

3 recordsLinked to original sources

arXiv2026

The Invisible Scheduler: Dragging a Sprite Can Change What a Scratch Program Does

Tens of millions of children program in Scratch, whose programs are concurrent: when the green flag is clicked, every sprite's scripts start together and share the project's state. Which script starts first is decided by the sprites' front-to-back stacking order, which no block reads. Dragging a sprite brings it to the front, and the order is saved with the project. Hence, a program can work on the author's screen and fail on the teacher's, with the same blocks. Our key observation is that, with the rest of the file fixed, rearranging the sprites that start scripts among their positions produces exactly the permutations of their initial stacking order. Under a fixed input and seed the unmodified virtual machine reproduces every one of them. StackSwap runs a project under these orders, all of them for up to five sprites, one per class of a conflict graph beyond, and a sample where neither is feasible, and compares the runs under four observation lenses. It returns a two-run witness naming an adjacent pair of sprites whose swap changes the outcome, with the resources they share as candidate causes; otherwise an exhaustive or graph-conditional robustness certificate, or an unresolved verdict. On 767 real programs from a course, an online judge, and a random public sample, 26.4% (course) and 18.2% (public) of those with a scheduling choice behave differently under some stacking order. Among the sensitive programs whose every order ran, the saved order's outcome recurs under a median 17% (course) and 50% (public) of the orders. Under scripted play, a predicate written from a stated requirement holds under one order and fails under another for 5 of 427 student submissions with a scheduling choice. For half of the sensitive programs the random stream is the racing pair's highest-priority shared resource. We close with recommendations for learners, graders, and the Scratch platform.

cs.SE↗

arXiv2026

The Invisible Throttle: Running on Borrowed Time in Scratch

Scratch has 135 million registered users, most of them children, and 164 million shared projects. What they are taught about the speed of a script fits in one sentence: a loop iterates once per frame. Unfortunately, that sentence describes the exception. In the public virtual machine a frame repeats the scripts until something visible asks the screen to redraw, no script is left running, or three quarters of the frame's wall-clock time are spent. Hence a loop that does not draw is paced by whatever else is visible and by the machine. Hide the moving sprite of a two-sprite project, and the other's counting loop runs 77,000 times faster on a laptop. No documentation states the rule. Our key observation is that the redraw gate is one flag for the whole runtime, so a loop's speed can be changed without touching its code: hide the sprite that draws, change the machine's budget, or run the program in a tool with no renderer. ThrottleCheck implements a budgeted semantics (a stated budget of rounds per frame, the redraw gate emulated) on the unmodified virtual machine, runs a project under each knob, and reports a rate-sensitive project with a witness. On 500 popular public games, 59% contain a loop that never draws and never waits. Muting the requests of the sprites that draw changes the state of a played game after ten seconds in 24% of the games that have one; hiding them changes 18%; running the game without a renderer and without the gate changes 61%. Rules that read a position, a score or a clock after a fixed time reverse between pass and fail once the throttle is released, in 17% of Whisker's own example tests and 19% of a tutorial's checks on 224 of its remixes. A grader without a renderer grades a program the editor never runs, unless it emulates the gate and states a budget; we say what graders and the platform should do, and close with the sentence a child could be taught.

cs.SE↗

arXiv2025

Hierarchical Structure Sharing Empowers Multi-task Heterogeneous GNNs for Customer Expansion

Customer expansion, i.e., growing a business existing customer base by acquiring new customers, is critical for scaling operations and sustaining the long-term profitability of logistics companies. Although state-of-the-art works model this task as a single-node classification problem under a heterogeneous graph learning framework and achieve good performance, they struggle with extremely positive label sparsity issues in our scenario. Multi-task learning (MTL) offers a promising solution by introducing a correlated, label-rich task to enhance the label-sparse task prediction through knowledge sharing. However, existing MTL methods result in performance degradation because they fail to discriminate task-shared and task-specific structural patterns across tasks. This issue arises from their limited consideration of the inherently complex structure learning process of heterogeneous graph neural networks, which involves the multi-layer aggregation of multi-type relations. To address the challenge, we propose a Structure-Aware Hierarchical Information Sharing Framework (SrucHIS), which explicitly regulates structural information sharing across tasks in logistics customer expansion. SrucHIS breaks down the structure learning phase into multiple stages and introduces sharing mechanisms at each stage, effectively mitigating the influence of task-specific structural patterns during each stage. We evaluate StrucHIS on both private and public datasets, achieving a 51.41% average precision improvement on the private dataset and a 10.52% macro F1 gain on the public dataset. StrucHIS is further deployed at one of the largest logistics companies in China and demonstrates a 41.67% improvement in the success contract-signing rate over existing strategies, generating over 453K new orders within just two months.

cs.LG↗