profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/purcell/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Steve Purcell purcell Wellington, New Zealand http://www.sanityinc.com/ I simplify and optimise software and human systems.

melpa/melpa 2212

Recipes and build machinery for the biggest Emacs package repo

magnars/multiple-cursors.el 1870

Multiple cursors for emacs.

bbatsov/emacs-lisp-style-guide 888

A community-driven Emacs Lisp style guide

eschulte/rinari 415

Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)

jcollard/elm-mode 363

Elm mode for emacs

congomongo/congomongo 354

Clojure wrapper for the mongo-db java api

asok/projectile-rails 245

Emacs Rails mode based on projectile

nex3/haml-mode 140

Emacs mode for Haml.

jlr/rainbow-delimiters 111

Emacs rainbow delimiters mode

purcell/ac-slime 111

Emacs auto-complete plugin for Slime symbols

startedpurcell/exec-path-from-shell

started time in 3 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

It seems that in GUI mode there's never a call into encode_coding_object.

So to summarize: It seems that we generate a lot of unreachable markers in haskell-lexeme.el with looking-at. These markers cause a slow-down in encoding_coding_object which traverses the list of markers once or twice. That function is then called on redisplay on terminal mode, causing a delay on drawing each line. However, the function is never called in GUI mode.

A garbage collect would instantly bring the performance back to normal, but especially lsp-users are likely to want a high gc-cons-threshold. Also, generating this much markers causes a noticeable increase in GC delay.

Normally this wouldn't bother me as much, but I regularly trip into this the problem while doing very normal code editing - granted the scrolling speed does not get as bad as in the text-case after 4-5 cut+paste, but it's noticably sluggish nevertheless.

Assuming my hypothesis is correct:

As a user workaround I can see

  1. Reducing gc-cons-threshold
  2. Using something like gcmh
  3. Switching to GUI mode

For a solution: Can we reduce the amount of generating markers somehow?

dminuoso

comment created time in 8 hours

startedpurcell/exec-path-from-shell

started time in 8 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

I suspect this to be the culprit:

https://github.com/haskell/haskell-mode/blob/b35e8547b67f3d2c4d38ec7e7e516e3c0925352f/haskell-lexeme.el#L106

Is it possible that the frequent call of this during font locking generates a lot of match data with markers, that don't get cleaned up? If that's the case, why don't I notice the scrolling problem in GUI mode?

dminuoso

comment created time in 9 hours

pull request commentmelpa/melpa

Add simple-tree recipe

It seems like much of the functionality of this package is provided by Emacs bookmarks.

Sasanidas

comment created time in 9 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

Hi. i was asked by the issue author to help with confirming/reproducing the issue.

i'd like to report back that, after following the explicit steps and conditions here i can reproduce the issue on my machine to degrade scroll performance to the point of being sluggish in terminal mode (emacs -nw) (did not test gui)

it seems to get a lot better / came back to normal after i ran (garbage-collect), which also goes with the expected observation in the issue.

my emacs is compiled from source.

i was also asked to provide the output of C-h v system-configuration-options , which is as follows

system-configuration-options is a variable defined in ‘C source code’.

Its value is
"--with-native-compilation --with-json --with-pgtk --with-modules --with-mailutils --without-pop --without-xwidgets"

String containing the configuration options Emacs was built with.

hope it helps!

dminuoso

comment created time in 11 hours

startedpurcell/disable-mouse

started time in 11 hours

push eventmelpa/melpa

Chen Bin

commit sha 51f723347f56e150852bf82d163c04aa846a3d9c

Add shellcop recipe (#7604)

view details

push time in 14 hours

PR merged melpa/melpa

Add recipe shellcop

Brief summary of what the package does

Analyze info&error in shell-mode

Direct link to the package repository

https://github.com/redguardtoo/shellcop

Your association with the package

I'm the maintainer

Relevant communications with the upstream package maintainer

None needed

Checklist

<!-- Please confirm with x: -->

  • [x] The package is released under a GPL-Compatible Free Software License
  • [x] I've read CONTRIBUTING.org
  • [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
  • [x] My elisp byte-compiles cleanly
  • [x] M-x checkdoc is happy with my docstrings
  • [x] I've built and installed the package using the instructions in CONTRIBUTING.org
  • [ ] I have confirmed some of these without doing them

<!-- After submitting, please fix any problems the CI reports. -->

+1 -0

3 comments

1 changed file

redguardtoo

pr closed time in 14 hours

pull request commentmelpa/melpa

Add recipe shellcop

Thank you!

redguardtoo

comment created time in 14 hours

issue openedpurcell/package-lint

Acceptable prefixes: should `toggle-` be on the list?

The const package-lint--sane-prefixes lists some exceptional prefixes that package-lint will let slide. These have been super useful, so thanks.

It seems another common prefix is toggle, which came up in this recent MELPA PR.

toggle seems to be a popular prefix across packages -- especially builtins. One very small disadvantage I see is that there is a package called toggle indexed on MELPA. Altogether I don't see it as a problematic prefix, but I'm a consistency hobgoblin and it would be nice if the exception were codified in package-lint, should that make sense.

@rnkn fyi.

created time in 14 hours

pull request commentmelpa/melpa

Add simple-tree recipe

Friendly ping. :) I think the only outstanding issue is the name. Naming is of course a subjective thing, so if you're adamant on simple-tree we could ask for a third party to chime in.

I notice one checkdoc regarding this error message: "Project %s already exist." which should be "Project %s already exists"

Sasanidas

comment created time in 15 hours

pull request commentmelpa/melpa

Add recipe for frontside-windowing

Friendly ping. :)

cowboyd

comment created time in 15 hours

pull request commentmelpa/melpa

Add recipe for org-super-links

@toshism I'll mark this awaiting-upstream, there's no rush. (Thanks again @alphapapa for chiming in.)

toshism

comment created time in 15 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

Underlying issue for the test-case appears to be a large accumulation of unreachable markers in the buffer. encode_coding_object traverses the singly linked of markers at least once, potentially twice.

https://git.savannah.gnu.org/cgit/emacs.git/tree/src/coding.c?h=emacs-27.1&id=86d8d76aa36037184db0b2897c434cdaab1a9ae8#n8281

In the degenerate case this singly linked list can contain millions of elements, causing the slowdown.

What is haskell-font-lock.el doing to make this problem so apparent, even when editing smaller code regions?

dminuoso

comment created time in 17 hours

startedpurcell/emacs.d

started time in 17 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

gprof agrees:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 96.23    160.67   160.67    32275     4.98     4.98  encode_coding_object

5ms per call into encode_coding_object makes for absolute horrid performance I guess.

dminuoso

comment created time in 18 hours

issue commenthaskell/haskell-mode

Degrading scroll performance in terminal mode

It seems that 75% of the time is spent in encode_coding_object

Attached you can find the perf_events report and flamegraph.

perf_report.gz out.svg.gz out.perf.gz

 Samples: 4K of event 'cycles'
# Event count (approx.): 112485425315
#
# Children      Self       Samples  Command          Shared Object          Symbol                                        
# ........  ........  ............  ...............  .....................  ..............................................
#
    99.67%     0.00%             0  .emacs-27.1-wra  [unknown]              [k] 0x41fd89415541f689
            |
            ---0x41fd89415541f689
               __libc_start_main
               main
:
               recursive_edit_1
               command_loop
               internal_catch

               internal_condition_case
               command_loop_1
               |          
               |--77.34%--read_key_sequence
               |          |          
               |           --77.28%--read_char
               |                     |          
               |                      --77.22%--redisplay_internal
               |                                |          
               |                                |--75.83%--update_frame
               |                                |          update_frame_1
               |                                |          update_frame_line
               |                                |          tty_write_glyphs
               |                                |          |          
               |                                |           --75.81%--encode_terminal_code

               |                                |                      --75.76%--encode_coding_object
               |                                |          
dminuoso

comment created time in 19 hours

issue openedhaskell/haskell-mode

Degrading scroll performance in terminal mode

The Problem

Since I switched to emacs I noticed how scrolling sporadically became worse. At times, it would take 3-4s to redraw 40 lines of code.

Apparent relevant factors

After doing a lot of analyzing I narrowed it down to the following combination of things:

  1. Emacs must run in terminal, in GUI either the problem is not as apparent or its non-existant.
  2. gc-cons-threshold must be set to a high value. LSP users likely have something like (setq gc-cons-threshold 100000000)
  3. haskell-mode and font-lock-mode must be enabled
  4. Do some text editing

Watch drawing lines become slower. The presence of constructor names seems especially bad. Note, that the entire line is drawn much slower, so if you vertically tile your emacs to have some unrelated buffer on the right hand side, then the entire line with many data constructors on the left hand window will be drawn slowly.

  1. If you then cause a (garbage-collect), scrolling becomes fast again.

Reproduce

Locally I used emacs 27.1 installed through the emacs nix overlay:

<details> <summary>Click to see/use my nixos module</summary> <p>

{ config, pkgs, ... }:

let
  emacsOverlay = import (builtins.fetchTarball {
  # Descriptive name to make the store path easier to identify
    name = "emacs-overlay-2020-09-11";
    # Commit hash for nixos-unstable as of 2018-09-12
    url = https://github.com/nix-community/emacs-overlay/archive/a69588a3f7de6d68f20cea21562ab7f6f91a400a.tar.gz;
    # Hash obtained using `nix-prefetch-url --unpack <url>`
    sha256 = "180jp31zfrlhnz490x6hckz6z3bvfxwz1613cg4zmf0lrflrl3gp";
  });

  myEmacs = pkgs.emacs;
  emacsWithPackages = (pkgs.emacsPackagesGen myEmacs).emacsWithPackages;
  emacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
  # melpa stable
    ripgrep
    magit
    # dockerfile-mode
    # markdown-mode
    # yaml-mode
    # json-mode
    # go-mode
    # nix-mode
    use-package
    projectile
    # direnv
    # swiper
    # ox-gfm
    # pdf-tools
  ]) ++ (with epkgs.melpaPackages; [
  # melpa unstable
    solarized-theme
    gruvbox-theme
    company
    counsel
    counsel-projectile
    ivy
    evil
    evil-collection
    evil-magit
    haskell-mode
    lsp-mode
    lsp-ui
    lsp-haskell
    lsp-treemacs
    treemacs
    flycheck
  ]) ++ (with epkgs.elpaPackages; [
  # elpa packages
    undo-tree
  ]) ++ [
  # main packages
  ]);
in

{
  nixpkgs.overlays = [emacsOverlay];

  services.emacs.enable = true;
  services.emacs.install = true;
  services.emacs.defaultEditor = true;
  services.emacs.package = emacs;
}

</p> </details>

  1. Ensure you do not have undo-tree-mode enabled. This minor mode causes frequent garbage collections with the test-case, leading to inconsistent behavior.
  2. Download the attached test file
  3. Set (setq garbage-collection-messages t) to have emacs tell you if a GC is run Note: This is just for your own sanity so you do know if for some reason there's an unexpected.
  4. Set (setq gc-cons-threshold most-positive-fixnum) Note: We use the highest value to ensure the GC doesn't interfere with our testcase due to some unforseen circumstances. It's an unreasonable value for the real world.
  5. Repeatedly cut+paste the block below the definition of info. Ideally keep a small terminal (say 80x24), this lets you see the redisplay of the definitions of info Attr ... nicely during cut+paste.

Watch the performance degrade with every cut+paste.

  1. Run a (garbage-collect) and watch performance be fast again.

Notes of interest:

  1. If the block at the end is wrapped inside a comment, performance stays stable during cut+paste
  2. If the block at the end is just un-font-locked, performance degrades during cut+paste
  3. The redisplay degradation is particularly linked to the font locking on data constructors. If we add more data constructors in those definitions of info, then the performance degradation is much worse.
  4. The redisplay performance extends to the entire frame, not just the buffer. Two ways to demonstrate this: If you resize the frame to full screen, watch how every line including toolbar and mode line is drawn slowly too. You can also create horizontal/vertical split windows, and watch how these get redrawn slowly too when the frame is switched between full screen and windowed.
  5. The problem is reproducible with undo-tree-mode present, (setq gc-cons-threshold 100000000) and normal editing of text. Often writing a 60 line region can cause quite bad performance degradation already, it's just more inconsistent. This I want to point out before someone makes a comment about how repeatedly cut+paste on 10k lines of code is not normal emacs usage. This is just a synthesized test case with a clear communicatable description how to reproduce.
  1. The emacs profiler does not help at all.
  2. During degraded performance, the CPU usage spikes to 100% while scrolling.

Profiler output

If the performance has degraded, running the profiler while scrolling up and down for a minute gives these CPU and Memory reports

CPU Profiler output

<details> <summary>Click me to expand!</summary> <p>

 Function                                                  CPU samples    %                                                                                                                                                                                                                                                                                                
- command-execute                                                3417  99%                                                                                                                                                                                                                                                                                                 
 - call-interactively                                            3417  99%                                                                                                                                                                                                                                                                                                 
  - funcall-interactively                                        3284  96%                                                                                                                                                                                                                                                                                                 
   - execute-extended-command                                    2300  67%                                                                                                                                                                                                                                                                                                 
    - sit-for                                                    2287  66%                                                                                                                                                                                                                                                                                                 
     - redisplay                                                 2287  66%                                                                                                                                                                                                                                                                                                 
      + redisplay_internal (C function)                             1   0%                                                                                                                                                                                                                                                                                                 
    + command-execute                                              12   0%                                                                                                                                                                                                                                                                                                 
     scroll-down-command                                          534  15%                                                                                                                                                                                                                                                                                                 
   - scroll-up-command                                            450  13%                                                                                                                                                                                                                                                                                                 
    + scroll-up                                                     1   0%                                                                                                                                                                                                                                                                                                 
  + byte-code                                                     133   3%                                                                                                                                                                                                                                                                                                 
+ evil-repeat-post-hook                                             1   0%                                                                                                                                                                                                                                                                                                 
  evil--jump-hook                                                   1   0%                                                                                                                                                                                                                                                                                                 
+ timer-event-handler                                               1   0%                                                                                                                                                                                                                                                                                                 
+ ...                                                               0   0%      

</details> </p>

Memory profiler output

<details> <summary>Click me to expand!</summary> <p>

 Function                                                        Bytes    %                                                                                                                                                                                                                                                                                                
- command-execute                                           8,755,700  99%                                                                                                                                                                                                                                                                                                 
 - call-interactively                                       8,755,700  99%                                                                                                                                                                                                                                                                                                 
  - byte-code                                               4,469,695  50%                                                                                                                                                                                                                                                                                                 
   - read-extended-command                                  4,469,695  50%                                                                                                                                                                                                                                                                                                 
    - completing-read                                       4,469,695  50%                                                                                                                                                                                                                                                                                                 
     - ivy-completing-read                                  4,469,695  50%                                                                                                                                                                                                                                                                                                 
      - ivy-read                                            4,469,695  50%                                                                                                                                                                                                                                                                                                 
       - read-from-minibuffer                               2,628,499  29%                                                                                                                                                                                                                                                                                                 
        + ivy--queue-exhibit                                2,068,301  23%                                                                                                                                                                                                                                                                                                 
        + command-execute                                      49,096   0%                                                                                                                                                                                                                                                                                                 
        + redisplay_internal (C function)                      12,416   0%                                                                                                                                                                                                                                                                                                 
        + minibuffer-inactive-mode                              7,392   0%                                                                                                                                                                                                                                                                                                 
        + #<compiled 0x472e8f9>                                 1,056   0%                                                                                                                                                                                                                                                                                                 
        + undo-auto--add-boundary                               1,056   0%                                                                                                                                                                                                                                                                                                 
        + undo-auto--undoable-change                               72   0%                                                                                                                                                                                                                                                                                                 
       + ivy--reset-state                                     256,404   2%                                                                                                                                                                                                                                                                                                 
       + ivy-call                                               1,056   0%                                                                                                                                                                                                                                                                                                 
       + ivy--update-prompt                                     1,024   0%                                                                                                                                                                                                                                                                                                 
  - funcall-interactively                                   4,286,005  48%                                                                                                                                                                                                                                                                                                 
   - execute-extended-command                               4,259,293  48%                                                                                                                                                                                                                                                                                                 
    - command-execute                                       3,791,263  43%                                                                                                                                                                                                                                                                                                 
     - call-interactively                                   3,791,263  43%                                                                                                                                                                                                                                                                                                 
      - funcall-interactively                               3,791,247  43%                                                                                                                                                                                                                                                                                                 
         profiler-stop                                      3,790,592  43%                                                                                                                                                                                                                                                                                                 
         profiler-start                                           655   0%                                                                                                                                                                                                                                                                                                 
    + sit-for                                                 273,374   3%                                                                                                                                                                                                                                                                                                 
   + scroll-down-command                                       15,960   0%                                                                                                                                                                                                                                                                                                 
   + scroll-up-command                                         10,752   0%                                                                                                                                                                                                                                                                                                 
+ redisplay_internal (C function)                              23,224   0%                                                                                                                                                                                                                                                                                                 
+ jit-lock--antiblink-post-command                              8,360   0%                                                                                                                                                                                                                                                                                                 
+ timer-event-handler                                           6,200   0%                                                                                                                                                                                                                                                                                                 
  evil--jump-handle-buffer-crossing                             2,112   0%                                                                                                                                                                                                                                                                                                 
+ global-font-lock-mode-check-buffers                           1,056   0%                                                                                                                                                                                                                                                                                                 
+ internal-echo-keystrokes-prefix                               1,056   0%                                                                                                                                                                                                                                                                                                 
  ...                                                               0   0%                 

</details> </p>

GC Output

I first did cut+paste to degrade performance, then executed two (garbage-collect) in a row

The first, which fixed performance, gave us the following output

<details> <summary>First GC (After degraded performance): Click me to expand!</summary> <p>

((conses 16 4979055 645610)
 (symbols 48 93078 29)
 (strings 32 158480 15678)
 (string-bytes 1 8876291)
 (vectors 16 92580)
 (vector-slots 8 1958997 416166)
 (floats 8 336 1527)
 (intervals 56 1006222 9317)
 (buffers 1000 42))                                                                                                                                                

</p> </details>

Second GC, immediately again. This is just to observe whether the first GC has collected huge amounts of memory. Note: It did not. The output is very similar to that of the run before. <details> <summary>First GC (After degraded performance): Click me to expand!</summary> <p>

((conses 16 4947118 644997)
 (symbols 48 93078 29)
 (strings 32 158477 15588)
 (string-bytes 1 8875403)
 (vectors 16 92579)
 (vector-slots 8 1958985 414138)
 (floats 8 336 1527)
 (intervals 56 1006220 9301)
 (buffers 1000 42))                                                                                                                                            

</p> </details>

created time in 21 hours

startedpurcell/mmm-mode

started time in a day

issue commentpurcell/emacs.d

The order of company candidates is incorrect in Emacs lisp mode

Hi, @purcell
Now we have changed the completion style to (setq completion-styles '(basic partial-completion orderless)) globally, this also affect the completion in minibuffer. Now the behavior is like this: before

I think it is better to set minibuffer completion-styles to use only orderless to get a better experience.
something like this would work.

    (defun sanityinc/use-orderless-in-minibuffer ()
    (interactive)
    (setq-local completion-styles '(orderless)))
  (add-hook 'minibuffer-setup-hook 'sanityinc/use-orderless-in-minibuffer)

Now it the behavior is like this: after

Eason0210

comment created time in a day

push eventmelpa/melpa

Jonas Bernoulli

commit sha b6d136b1033d9afdea965ab07ba7c05e9ecf56e5

Add ol-notmuch recipe

view details

push time in a day

delete branch melpa/melpa

delete branch : ol-notmuch

delete time in a day

create barnchmelpa/melpa

branch : ol-notmuch

created branch time in a day

PR opened melpa/melpa

Add recipe for uci-mode

Brief summary of what the package does

An Emacs major-mode for chess engine interaction. This is a dependency for the more interesting library pygn-mode, to be submitted separately.

Direct link to the package repository

https://github.com/dwcoates/uci-mode

Your association with the package

A contributor, on behalf of @dwcoates .

Relevant communications with the upstream package maintainer

None needed.

Checklist

<!-- Please confirm with x: -->

  • [x] The package is released under a GPL-Compatible Free Software License
  • [x] I've read CONTRIBUTING.org
  • [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
  • [x] My elisp byte-compiles cleanly
  • [x] M-x checkdoc is happy with my docstrings
  • [x] I've built and installed the package using the instructions in CONTRIBUTING.org
  • [ ] I have confirmed some of these without doing them

<!-- After submitting, please fix any problems the CI reports. -->

+3 -0

0 comment

1 changed file

pr created time in a day

startedpurcell/ibuffer-vc

started time in a day

PR opened melpa/melpa

add rsync-mode recipe

Brief summary of what the package does

A minor mode to keep repositories in sync using the rsync command line tool.

Direct link to the package repository

https://github.com/r-zip/rsync-mode

Your association with the package

I am the primary author. The only other contributor is ajwhite445. @ajwhite445

Relevant communications with the upstream package maintainer

None needed.

Checklist

<!-- Please confirm with x: -->

  • [x] The package is released under a GPL-Compatible Free Software License
  • [x] I've read CONTRIBUTING.org
  • [x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback
  • [x] My elisp byte-compiles cleanly
  • [x] M-x checkdoc is happy with my docstrings
  • [x] I've built and installed the package using the instructions in CONTRIBUTING.org
  • [ ] I have confirmed some of these without doing them

<!-- After submitting, please fix any problems the CI reports. -->

+1 -0

0 comment

1 changed file

pr created time in 2 days

Pull request review commenttezos-checker/checker

Initial stress test for liquidation auction

 def call_checker_endpoint(name, param, amount=0):         print(json.dumps(gas_costs_sorted, indent=4))  +class LiquidationsStressTest(SandboxedTestCase):+    def test_liquidations(self):+        print("Deploying the mock oracle.")+        oracle = deploy_contract(+            self.client,+            source_file=os.path.join(PROJECT_ROOT, "util/mock_oracle.tz"),+            initial_storage=(self.client.key.public_key_hash(), 1000000),+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deploying ctez contract.")+        ctez = deploy_ctez(+            self.client,+            ctez_dir=os.path.join(PROJECT_ROOT, "vendor/ctez"),+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deploying Checker.")+        checker = deploy_checker(+            self.client,+            checker_dir=CHECKER_DIR,+            oracle=oracle.context.address,+            ctez=ctez["fa12_ctez"].context.address,+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deployment finished.")++        def call_endpoint(contract, name, param, amount=0):+            print("Calling", contract.key.public_key_hash(), "/", name, "with", param)+            return inject(+                self.client,+                getattr(contract, name)(param)+                .with_amount(amount)+                .as_transaction()+                .autofill(ttl=MAX_OPERATIONS_TTL)+                .sign(),+            )++        def call_bulk(bulks, *, chunk_size):+            chunks = [+                bulks[i : i + chunk_size] for i in range(0, len(bulks), chunk_size)+            ]+            for chunk_no, chunk in enumerate(chunks, 1):

This isn't super critical, but I am wondering if using the term "batch" instead of "chunk" would be more descriptive here since we also use "chunk" in our deployment script to describe chunks of bytes.

utdemir

comment created time in 2 days

Pull request review commenttezos-checker/checker

Initial stress test for liquidation auction

-{ doCheck ? false }:+{ doCheck ? false, e2eTestsHack ? false }:

Nice :smile:

utdemir

comment created time in 2 days

Pull request review commenttezos-checker/checker

Initial stress test for liquidation auction

 def call_checker_endpoint(name, param, amount=0):         print(json.dumps(gas_costs_sorted, indent=4))  +class LiquidationsStressTest(SandboxedTestCase):+    def test_liquidations(self):+        print("Deploying the mock oracle.")+        oracle = deploy_contract(+            self.client,+            source_file=os.path.join(PROJECT_ROOT, "util/mock_oracle.tz"),+            initial_storage=(self.client.key.public_key_hash(), 1000000),+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deploying ctez contract.")+        ctez = deploy_ctez(+            self.client,+            ctez_dir=os.path.join(PROJECT_ROOT, "vendor/ctez"),+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deploying Checker.")+        checker = deploy_checker(+            self.client,+            checker_dir=CHECKER_DIR,+            oracle=oracle.context.address,+            ctez=ctez["fa12_ctez"].context.address,+            ttl=MAX_OPERATIONS_TTL,+        )++        print("Deployment finished.")++        def call_endpoint(contract, name, param, amount=0):+            print("Calling", contract.key.public_key_hash(), "/", name, "with", param)+            return inject(+                self.client,+                getattr(contract, name)(param)+                .with_amount(amount)+                .as_transaction()+                .autofill(ttl=MAX_OPERATIONS_TTL)+                .sign(),+            )++        def call_bulk(bulks, *, chunk_size):

Not sure if we need the * in this signature

utdemir

comment created time in 2 days