Design specification for JupyterLab navigation bar

This is where I will be posting the design specifications for the navigation bar to iterate on!

Here is what I have come up with for the navigation bar:

For each dropdown item, we were planning on the font size to be 12px with a 4px margin on the top and the bottom, equating to a total of 20px of height per dropdown item. But, we found that on many web applications and in web typography in general, 12px is too hard to read. So, we decided on making the base font size in both the navigation and the content area to 13px. This now makes it, with a 4px margin on the top and bottom, to a height of 21px per cell. At the top and bottom of each menu, as well as for the dividers between sections, there is a 4px margin that is used. Lastly, in regards to the single margin between the revert to checkpoint dropdown item and the expansion arrow to it's right, I was thinking that there would be a 12px margin between the longest in length menu item and either the side of the menu dropdown or addition content on the right:
Margin Specifications

There weren't enough stylings in the menus for me to make a complete specification, so here are the specifications for each item in the dropdown menu including the hover state:
Color & Typography Specifications

Cell Title (ex. New, Open..., Close):
Font family: Helvetica Neue
Font weight: Regular
Font size: 13px
Color: #757575
Cell Right Justified Title (Command)
Font family: Lucida Grande
Font weight: Regular
Font size: 13px
Color: #9E9E9E
Cell Right Justified Arrow
navbar-arrow.svg.zip
Color: #9E9E9E
Hover State Color: #757575
Cell Hover State Background Color
Background Color: #EEEEEE

Why not use electron/nw.js and use native menu whenever possible.

If "whenever possible" was 99% then sure than makes a ton of sense. But hosted/online deployments are becoming more and more important so we have to maintain a strong "browser first" philosophy. A great example is UC Berkeley which is starting to teach every single student data science using a hosted/online version of JupyterHub.
Also, if you design for the browser, the moving to something like electron isn't too bad. Moving the other way is more difficult because the browser lack things (like menus, sane keyboard handling, tabs/panels, etc.).

An issue with these specs is that it is all on OS X retina, and does not reflect how things are going to look like on other platforms (Windows, Linux, OS X non-retina).
Screenshots should rather be done on low-definition screens, and the zoom applied after the screenshot, with a tool that will not use a smoothing algorithm for the image upscaling, such as taking a screenshot of a gimp/photoshop zoomed-in image...

This might be a personal opinion but this kind of pixel specs seem a bit out of touch with the actual web development.

Lucida Grande is on like 0% of windows/linux so font stack needs to be established rather than single font
Heights of the cells should be defined in terms of the font size (in percent or em)
No way the shortcuts would fit on other platforms (but I think they are great)

@bliker agreed. Although font-based icons have specific requirements in font-size to be sharp (pixel-perfect).


3.9.0 docker image not working on Apple Silicon (M1)

My Environment

ArangoDB Version:        3.9.0
Deployment Mode:       Single Server
Deployment Strategy:   Manual Start in Docker
Configuration:
Infrastructure:               locally
Operating System:        MacOS 12.2.1
Total RAM in your machine:        32GB
Disks in use:        SSD
Used Package:              Docker - official Docker library

Component, Query & Data
Affected feature:
Installation | startup
Steps to reproduce

docker pull arangodb:3.9.0 --platform=linux/amd64
docker run -e ARANGO_RANDOM_ROOT_PASSWORD=1 -p 8529:8529 -it arangodb:3.9.0 --platform linux/amd64

Problem:
ArangoDB crashes with the error message qemu: uncaught target signal 4 (Illegal instruction) - core dumped
I have had no issues running 3.8.5 or the 3.8.4 before it. But the new 3.9.0 doesn't work on my M1 Pro.
Expected result:
ArangoDB starts

please note that the docker container is most probably run via docker / linux / Rosetta;
This doesn't wrap SSE2 commands which are required by the binaries, hence they're killed by SIG_ILL.
I think the nightlies however work in such a setup.

Same issue with 3.9.0 nightly and 3.9.1 nightly

ok, I guess 3.9 is the first release to turn on SSE2 for all linux binaries.
you can probably try one of the ARM Linux nightlies published by @Programmador: https://github.com/arangodb/arangodb-docker/issues/53
We will be working on linux ARM binaries for 3.10 in the next weeks; these should run without rosetta and hence work flawless.

Sorry, thats all we can currently offer for M1 for the time being. The situation is going to improve in the next weeks.

@sillen102 3.9+ branch requires AVX which isn't emulated by Rosetta. 3.8 didn't have this requirement. We have native ARM support in our roadmap but not for 3.9 at the moment.

We will provide special Docker images of ArangoDB 3.9 (nightly and release versions) to allow you to develop on M1 hardware. These will still be linux/amd64 images but able to run on Apple silicon using the current Rosetta 2 emulation, matching the experience of 3.8 in the same context.
The images will have all functionality present in production images. However, they won't use AVX optimizations and will technically differ from 3.9 production images (potentially behaving in different ways under some unclear circumstances). Therefore, they should be used for development purposes only, and not in production.
The images come without official testing and support. The licensing for the Enterprise Edition is the same as for official releases.
First images are available for testing, more to follow:

arangodb/arangodb:3.9.0-noavx
arangodb/enterprise:3.9.0-noavx


Write ArgScript Parser

Is your feature request related to a problem? Please describe.
Need a functional ArgScript parser to address #20
Describe the solution you'd like
A functional ArgScript Parser
Describe alternatives you've considered
None

Putting this on hold as it's not strictly necessary for #20


Gradle 7.6 warns, task uses output without explicit dependency

When I run a Gradle build of our internal project I get this warning:
> Task :sunspot:compose:redwoodGenerate
Execution optimizations have been disabled for task ':sunspot:compose:redwoodGenerate' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/sunspot/compose/build/generated/redwood'. Reason: Task ':sunspot:compose:redwoodLintJvm' uses this output of task ':sunspot:compose:redwoodGenerate' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5/userguide/validation_problems.html#implicit_dependency for more details about this problem.
Gradle detected a problem with the following location: '/sunspot/compose/build/generated/redwood'. Reason: Task ':sunspot:compose:redwoodLintJvm' uses this output of task ':sunspot:compose:redwoodGenerate' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.5/userguide/validation_problems.html#implicit_dependency for more details about this problem. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. Execution optimizations are disabled to ensure correctness. See https://docs.gradle.org/7.5/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

Possibly related:
https://issuetracker.google.com/issues/253219347

We're way past 7.6 at this point. If it comes back we'll know.


New Pods/Workload status is red when first deploying

Rancher versions: 2.0 master 2/2
Steps to Reproduce:

Create a Pod or a Workload

Results:  The Activating status is red.  Makes it look like there is an error activating the pod/workload.  Starting status should be blue

UI shows red as the transitioning is error.
I think we need to change it in backend.

A duplicate of https://github.com/rancher/rancher/issues/11548


Nudge FilePicker launched from TokenConfig to redirect to root

Redirect to root is an array? Not a boolean?

Yep.


Revert change to fix POM pipelines.

Backing out my change to fix POM pipelines so I can take a closer look on a feature branch.

/azp run java - core


Make nvcc_detail/hip_runtime_api.h C compliant

This commit adds #ifdef control statements to make the header C compliant
In C++, member type declaration and setting default parameters to function arguments are possible
which may not be case with C. So appropriate #ifdefs and else are added to accomodate C compliance

The indentation of the code might be slightly off. I would like to know the coding guidelines that HIP team is following to ensure uniformity. I happen to see tabs in certain places and spaces in other.

Hi Neel – coding convention specifies spaces.  Sounds like we need to do a little housecleaning.
-ben
From: NEELMCW<EMAIL_ADDRESS>Reply-To: GPUOpen-ProfessionalCompute-Tools/HIP<EMAIL_ADDRESS>Date: Friday, November 18, 2016 at 4:11 AM
To: GPUOpen-ProfessionalCompute-Tools/HIP<EMAIL_ADDRESS>Subject: Re: [GPUOpen-ProfessionalCompute-Tools/HIP] Make nvcc_detail/hip_runtime_api.h C compliant (#49)
The indentation of the code might be slightly off. I would like to know the coding guidelines that HIP team is following to ensure uniformity. I happen to see tabs in certain places and spaces in other.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/GPUOpen-ProfessionalCompute-Tools/HIP/pull/49#issuecomment-261495643, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACYSAsLzIEXN3TVX-N_vqqGzJeyYbCc3ks5q_XnbgaJpZM4K2Tul.

Hi @NEELMCW ,
Can you test developer preview branch and create pull request based off it?


Updated README.md with svg badge

Coverage remained the same at 98.667% when pulling 125bdda767b92f142ed6f2bd84313bdde7da0bd3 on sobolevn:patch-1 into a3e1222460135fcc6e46c87904b92da979215bea on c-rack:master.

Coverage remained the same at 98.667% when pulling 125bdda767b92f142ed6f2bd84313bdde7da0bd3 on sobolevn:patch-1 into a3e1222460135fcc6e46c87904b92da979215bea on c-rack:master.


The icons of the blob containers and queues are not updated on the tree view

Storage Explorer Version: 1.20.0-dev
Build Number: 20210609.1
Branch: main
Platform/OS: Windows 10/ Fedora 34/ MacOS Big Sur 11.3
Architecture: ia32/x64
How Found: From running test case
Regression From: Not a regression
Steps to Reproduce

Expand one storage account.
Check the icons of the 'Blob Containers' & 'Queues' node.
Check whether the icons are updated.

Expected Experience
The icons are updated.
Actual Experience
The icons are not updated.

Additional Context
The icons on the connect dialog:

Verified on build main/20210610.4. Fixed.


Doctrine 2.5 - Entity Update Bug

I have the entity (this is simple example):
class Record
{
    /**
     * @ORM\Column(type="ContentContext_RecordTranslationCollection")
     * @var RecordTranslationCollection
     */
    private $translations;

    public function __construct()
    {
        $this->translations = new RecordTranslationCollection();
    }

    public function getTranslations(): RecordTranslationCollection
    {
        return $this->translations;
    }

    public function addTranslation(RecordTranslation $translation): void
    {
        /** @var RecordTranslation $translation */
        foreach ($this->translations as $currentTranslation) {
            if ($currentTranslation->getLocale() === $translation->getLocale()) {
                $this->translations->removeElement($currentTranslation);
                break;
            }
        }
        $this->translations->add($translation);
    }
}

My RecordTranslationCollection extends \Doctrine\Common\Collections\ArrayCollection
And my ContentContext_RecordTranslationCollection type looks like this:
class RecordTranslationCollectionType extends JsonType
{
    private $hydrator;

    public function setHydrator(Hydrator $hydrator)
    {
        $this->hydrator = $hydrator;
    }

    public function convertToDatabaseValue($collection, AbstractPlatform $platform)
    {
        $result = [];
        foreach ($collection as $entity) {
            $result[] = $this->hydrator->extract($entity);
        }

        return json_encode($result);
    }

    public function convertToPHPValue($json, AbstractPlatform $platform)
    {
        $data = json_decode($json, true) ?? [];
        $collection = new RecordTranslationCollection();
        foreach ($data as $translate) {
            $collection->add($this->hydrator->hydrate($translate, RecordTranslation::class));
        }
        return $collection;
    }

}

Ok, it all works when you create and save a new entity! But there is a problem when updating.
When I get the entity Record from the database to update the collection of translations, for example:
$record = // query to db ;

$translate1 = new RecordTranslation(); // for convenience, let's skip the data
$translate2 = new RecordTranslation(); // for convenience, let's skip the data

$record->addTranslation($translate1);
$record->addTranslation($translate2);

$this->entityManager->persist($record);
$this->entityManager->flush();

And my new collection does not save.
Doctrine does not understand that the object RecordTranslationCollection has changed.
And the method convertToDatabaseValue is not called.
If you use a spike, for example:
$r = new ReflectionProperty(get_class($record), 'translations');
$r->setAccessible(true);
$r->setValue($object, clone $record->getTranslations());

$this->entityManager->persist($record);
$this->entityManager->flush();

The entity will be saved correctly. So doctrine does not see the changes inside the object, but only see the object itself.

Changes to object properties are detected by reference so if the object (instance) does not change, it's deemed to be same. See description fo DateTime, it applies to objects in general: https://doctrine-orm.readthedocs.io/projects/doctrine-orm/en/latest/cookbook/working-with-datetime.html#datetime-changes-are-detected-by-reference

Also see https://stackoverflow.com/questions/15486402/doctrine2-orm-does-not-save-changes-to-a-datetime-field

I think littering in entities is doubtful. Maybe it's better to use a setting for example:
    /**
     * @ORM\Column(type="ContentContext_RecordTranslationCollection", updatable=true)
     * @var RecordTranslationCollection
     */
    private $translations;

In my case it will be easier to extend method persist, check properties of the entity on the availability of necessary objects and use clone there where it is should be.

"littering in entities"?

Sorry for my beginner's English.
I mean it's trash into entities.

No, it's just good practice to avoid sharing referentially kept mutable state by de-referencing via clone. See also https://ocramius.github.io/extremely-defensive-php/ and https://ocramius.github.io/doctrine-best-practices/ for further tips ;-)

Thank you very much!


Prepare skeleton

Initialise React app.
Add two s and s for the app's navigation, Books (the default view) and Categories:
Books displays the list of books with the Remove button.

Component called Book for displaying a single book.
Form for adding a book (separate component).

Categories:
displays a button "Check status".

Closing because linters not running


fix: Set serviceName on StatefulSets

In order for pods in a STS to "know" their FQDN (instead of just their hostname), the spec.serviceName attribute must be set. This will configure their FQDN to be
${metadata.name}.${spec.serviceName}.${metadata.namespace}.svc.cluster.local
One example where this is needed is when deploying a MongoDB Replicaset; Pods can only communicate with each other via the FQDN, not their hostnames alone; but they won't recognize "themselves" in the member list when they aren't aware of their own FQDN.
Checklist

[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog
[x] Update tests.

LGTM, thank you!

This change is breaking existing setups, and I think it should be reverted. This also needs a migration path.
The reason is that this tries to change the "serviceName" field of existing statefulSets, but that's not allowed: "updates to statefulset spec for fields other than 'replicas', 'ordinals', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"
I don't have a good idea yet how to fix this...

One way to fix this which worked for me: Delete the StatefulSet while keeping the PV, and let k8ify re-create the statefulSet.

The proper way to fix this problem is to use
kubectl -n <namespace> delete statefulset <name> --cascade=orphan
Note --cascade=orphan which will ensure that the pods associated with the StatefulSet that you’re deleting continue running.
Redeploy using k8ify immediately after, otherwise you might get issues later.


Speed up request buffered hashes

closes https://github.com/paradigmxyz/reth/issues/6148 and https://github.com/paradigmxyz/reth/issues/6308
speeds up requesting buffered hashes by
- [x] dividing hashes store (unknown_hashes, buffered_hashes[ and meta]) into eth68 and eth66. this means only hashes will be traversed that can be included in the request being assembled in fill_request_from_buffer_for_peer.

[x] improve performance and maintainability at cost of allocating memory for metadata for all hashes, regardless if seen in eth66 announcements only and hence have no metadata.
[x] use the transactions list on Peer type to search buffered_hashes after pop_any_idle_peer returns. that cache has capacity 10 240 and buffered hashes has capacity 25 600. also, then we just have to search buffered hashes, and not nested lists (even if they just default to 3 elements long) in buffered hashes for our peer returned by pop_any_idle_peer. effectivity of this is up to how well we can update the transactions list in the Peer type on-op. we will only update the transactions list on Peer type when we need to touch it anyway, on-op. we won't move around elements in lists of peer's seen transactions. it serves only as a hint to which hash cannot be pending, not as a perfect list of which hashes are pending. this totally satisfies requirements and otherwise it doesn't scale.

this is still very expensive because we blindly iterate all hashes in the hope the peer is the fallback, can we not keep track of the peer's hashes instead when registering them as fallback peers?

this is still very expensive because we blindly iterate all hashes in the hope the peer is the fallback, can we not keep track of the peer's hashes instead when registering them as fallback peers?

we don't even need to register any peer as fallback peer in that case, it's just double up storage of same data that can be derived by checking peer's seen txns against buffered hashes (buffered as in buffered for re-fetch or for first fetch if the hash didn't fit in the request that was triggered by processing the announcement in which the hash was seen the first time).

I think I can mostly follow along here, but the entire flow is not very obvious and needs to be properly documented.

Will use the discussion below as a base for docs.

My biggest concern with this is still that we're using the hashes as the main driver for creating requests and looping over all of them until the budget is exhausted.

The reason for this, is that, when a node has been operating for a while, the cache in the type Peer called transactions, will be at capacity all the time. Transactions are never deleted from that cache. On the other hand, the pending hashes cache will vary in size depending on network conditions. This means that having a budget for how many of the peer's seen transactions to loop through, doesn't really make sense. Having a budget on how many of the peer's seen transactions to loop through instead would mean that the oldest hashes seen by the peer, never get a chance to be fetched from that peer if they are pending. How it is now, that the budget is on how many pending hashes to loop through, leaves a chance for even the least recently used pending hashes to be fetched. This is because the pending hashes cache will be emptied of each hash that is fetched, so it gets smaller, meaning remaining hashes will be considered more recently used. Not having a budget is too risky, we need to be able to guarantee, that the operation of requesting pending hashes, will return within constant time when the node has high churn. TL;DR having a budget on how many of the transactions seen by the peer to loop through, doesn't make sense because that cache will eventually always be at capacity, whereas having a budget on how many pending hashes to loop through, makes sense because that cache shrinks when hashes are fetched.
Previously, it was mentioned that we should have a new mapping, peer->pending-hashes-seen-by-peer, for this purpose. Some questions and answers when considering introducing this new mapping here, make it clear why it isn't better:
When would we update it?
Every time we buffer some hashes on behalf of the peer we would add hashes to the mapping. Like for example, it couldn't fetch them because it was busy or because they didn't fit into the request. The mapping would be a subset of the mapping peer->transactions-seen-by-peer discussed in the previous paragraph, that is already existent.
So, when would we remove hashes from the mapping?
Every time a hash is successfully fetched. If that is the case, then we have the same problem we wanted to get away from originally because of time complexity: we would have to loop through all the mappings peer->pending-hashes-seen-by-peer, to check if the successfully fetched hash is in there and remove it. This would probably be more costly than the original problem of looping through fallback peers of all pending hashes, since the fallback peers cache had a capacity of just 3 peers, whereas this cache pending-hashes-seen-by-peer would have to have a far bigger capacity. Obviously we don't want that.
What do we do if we don't want to remove pending hashes upon successful fetch?
We leave it up to a bounded cache to do all the evictions.
What should the bound be on this cache?
We have no clue, it depends on how so many factors play together in the transaction fetcher and transaction manager code. So, we would make it big enough. This cache that we would have, would after the node has been running for a while, always be at capacity.
That's a lot of memory. For what price? How much efficiency in time complexity are we actually gaining here?
By the time we want to loop through the mapping for some peer, chances are high that some other peer has already fetched those hashes. So they are in fact not pending at all. This is the case since, the mempool is a gossip protocol, so redundancy of messages is a feature of the mempool. The possibility of keeping the mapping up to date, was out ruled, because it was too costly to loop through all the nested collections of pending hashes. So the gains in time complexity don't break even with the losses in space complexity.
We are absolutely loosing on space complexity, with the mapping peer->pending-hashes-seen-by-peer. Especially, considering that pending-hashes-seen-by-peer is a subset of the cache of all transactions seen by the peer, that is already available to use since before this pr, discussed in the first paragraph. This mapping that we already have, is an LruCache, which under the hood has a LinkedHashSet. Lookups in a hash set are O(1).
Additionally I implemented a separation of that cache into two, one containing hashes that can't possibly be pending and one containing hashes which have a chance of being pending, to decrease the likelihood of collisions. Hashes of transactions that are sent to the peer or have been received in full over broadcast from the peer, are added to the first. Hashes seen in an announcement are added to the second. This separation serves a decent decrease in chance of collision when looking up a hash in the peers seen hashes cache. It is not supposed to be a perfect separation of hashes that have been sent to or received from the peer in full. This means hashes are not moved from the transactions_received_as_hash cache and put in the transactions_received_in_full_or_sent cache when they are received in a response from fetching hashes - that would be too expensive for not much less chance of collision.
What I have implemented in terms of flow:
(i) Looping through the lru pending hashes, looking up the fallback peers for each hash, and checking if those peers are idle. On the first peer that is idle, stop looping. The likelihood that the lru or the second to lru pending hash has an idle fallback peer, is high. The fallback peers cache, has a capacity of 3 peers. I don't think this will be a problematic in terms of time complexity at all.
(ii) There is a peer from (i) along with one pending hash to request from it. Now the request will be filled up with more pending hashes. Loop through the pending hashes in lru order again, until a budget is depleted or the request is full. For each hash, look it up in the peers seen transactions mapping, the one for 'hashes that could be pending', transactions_received_as_hash. If it contains the hash, add it and update the total size.

it's not obvious what the difference between those two is
    /// Hashes that are awaiting an idle peer so they can be fetched.
    pub(super) hashes_pending_fetch: LruCache<TxHash>,
    /// Tracks all hashes in the transaction fetcher.
    pub(super) hashes_unknown_to_pool: LruMap<TxHash, T, Unlimited>,

besides one being bounded.

That is unintentional! They are both supposed to be bounded. I was thinking about what the bounds should be. The original bound, before the separation into two caches, was 10 * 1024. After some consideration, I increased them to 10 * 1024, but having both at 8 * 1024 should probably be fine. Adding metrics will be able to say after some time which portion of the original 10 * 1024 bytes, each holds. They sets of hashes in the two caches are disjoint.

we previously had a lot of debug panics, so I'd like to have a bit more test coverage for this. ideally also flamgraphing/samply a testnet node.

absolutely.

This is how the branch is looking on mainnet rn.

This is simply at commit 739d3c1
https://share.firefox.dev/3STlLDb
Will update with new samply from latest commit later.


Fix typo on makefile

Provide a description of what has been changed
Checklist

[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to #
During dive deep onto build file, I found a small typo.

/skip-e2e


Apple ARM gfortran should be updated

Apple ARM gfortran version 11.3 and 12.1 are released, yet conda only supplies v11.0.1.dev0.

Thanks for the update @isuruf. SciPy builds again after gh-61.


geoplotlib.geojson() method throws "ValueError: math domain error"

here is my python code.
import geoplotlib geoplotlib.geojson('bus.json') geoplotlib.show()
and here is the content of file "bus.json".
{   "type": "FeatureCollection",   "features": [     {       "type": "Feature",       "geometry": {         "type": "Point",         "coordinates": [           39.994238,           116.326786         ]       },       "properties": {         "prop0": "value0"       }     }   ] }
How could this happen?Any thing wrong?

@Silocean Looking at the code, there is no way something with the "type": "Feature" will be used.
The four types that get checked are:
if feature['geometry']['type'] == 'Polygon':
elif feature['geometry']['type'] == 'MultiPolygon':
elif feature['geometry']['type'] == 'Point':
elif feature['geometry']['type'] == 'LineString':

I'm receiving similar exception errors but for loading a dictionary into GeoPlotLib on ticket #46:
https://github.com/andrea-cuttone/geoplotlib/issues/46
Though I'm not passing my input through the geojson() function.


Stitching solids fails in some cases

NUMBA_DISABLE_JIT=1 python tests/geom/test_stitch_solids.py
Case 1: smaller polygon completely within a larger polygon

Case 1 fixed by: 222e12baf65c58478f5002797e65ed6e1a1fd4ca

Case 2: building.stitch_solids() doesn't work

Case 2 fixed: 27a6c67463aff0efcb3e173587820e54aec9e31a


Remove isRenewable logic for DNS Records and always allow in UI

We have UI code to check if a DNS Record isRenewable, which really never gets set to false. Let's always allow it.
The code was added in https://github.com/DevelopingSpace/starchart/pull/431, and we can just trim that out of the props, etc.

We just need to have renewable to never be disabled right?


feat(store): prune block function

Description
This PR implements the prune block function defined on PIP-27.
Related issue

Fixes #1391

@b00f For prune command in task #1392 we need to get public method to prune 1 block with transactions in loop.

@b00f For prune command in task #1392 we need to get public method to prune 1 block with transactions while pruning.

the pruneBlock is private


[CLOSED] Resource: Module 2 / Calling Functions

 Issue by jesseilev
Thursday Nov 05, 2015 at 23:38 GMT
Originally opened as https://github.com/Launch-Code/cs50x-live-2016/issues/3

Write a quick review of how to call a library function. Use strlen as example.
Talk about side effect vs return value. Mention printf as example of side effect.
Emphasize that you have to actually use the return value of the function by storing it in a variable or embedding the function call inside a larger expression, e.g. don't do this:
strlen("hello");

do this:
int len = strlen("hello");
// and now use len in your code

put it in this README

 Comment by brianrchen
Thursday Dec 03, 2015 at 21:34 GMT

uploaded first draft, needs formatting
also changed link in initial description of issue
EDIT:
formatted, could use a quick check

 Comment by brianrchen
Thursday Dec 03, 2015 at 23:16 GMT

Add new instructions to README

 Comment by digshake
Tuesday Dec 22, 2015 at 18:53 GMT

I went through this exercise and cleaned up the wording a bit. Closing this issue for now.

 Comment by brianrchen
Friday Dec 04, 2015 at 22:57 GMT

seems done, closing issue

 Comment by newjoiner
Monday Dec 28, 2015 at 19:11 GMT

@jesseilev
We can also add <string.h>, so if the students want to use strlen, they know to use that library.
Also do we want to add syntax highlighting like below?
#include <stdio.h>
#include <cs50.h>
#include <string.h>

int main(void)
{

    string exampleString = "hello!";

    // call strlen and store its return value in a variable
    int exampleStringLength = strlen(exampleString);

    printf("The string has %i characters!\n", exampleStringLength);
}

 Comment by jesseilev
Tuesday Dec 29, 2015 at 21:41 GMT

@newjoiner
Great catch. I totally forgot about <string.h>. I am afraid there might be a couple more instances where we talk about strlen without mentioning it, so keep your eye out.
Yes, syntax highlighting is awesome. From now on I will add syntax highlighting to any code blocks I write, and if you happen to come across some colorless blocks, go ahead and fix them. (But don't worry about trying to track down every last one.)
In case anyone is wondering, the way to add syntax highlighting in markdown is to specify the language after your opening 3 back-ticks, like this:

```c
```javascript

 Comment by jesseilev
Tuesday Dec 29, 2015 at 23:04 GMT

I added string.h and syntax highlighting, and wrote some more text.