othyn

Setting up a local only LLM (Qwen/Llama3/etc.) on macOS with Ollama, Continue and VSCode

As with a lot of organisations, the idea of using LLM's is a reasonably frightning concept, as people freely hand over internal IP and sensitive comms to remote entities that are heavily data bound by nature. I know it was on our minds when deciding on LLM's and their role within the team and wider company. 6 months ago, I set out to explore what offerings were like in the self-hosted and/or OSS space, and if anything could be achieved locally. After using this setup since then, and after getting a lot of questions on it, I thought I might share some of the things I've come across and getting it all setup.

Que in Ollama and Continue. Ollama is an easy way to locally download, manage and run models. Its very familiar to Docker in its usuage, and can probably be most conceptually aligned with it in how it operates, think imag

sezabass

name: PR Verification

on:
  push:
    branches:
      - develop
  pull_request:
jobs:
  pr-verification:
    runs-on: ubuntu-latest

sezabass

- name: Cache build runner
  uses: actions/cache@v2
  with:
    path: |
      **/.dart_tool
      **/*.g.dart
      **/*.mocks.dart
      **/*.config.dart
    key: build-runner-${{ hashFiles('**/asset_graph.json', '**/*.dart', '**/pubspec.lock', '**/outputs.json') }}
    restore-keys: |

sezabass

- name: Cache pubspec dependencies
  uses: actions/cache@v2
  with:
    path: |
      ${{ env.FLUTTER_HOME }}/.pub-cache
      **/.packages
      **/.flutter-plugins
      **/.flutter-plugin-dependencies
      **/.dart_tool/package_config.json
    key: build-pubspec-${{ hashFiles('**/pubspec.lock') }}

sezabass

- name: Cache flutter
  uses: actions/cache@v2
  with:
    path: |
      ${{ env.FLUTTER_HOME }}/bin
    key: install-flutter-1.22.6
    restore-keys: |
      install-flutter-

halilozercan

@Composable
fun CalendarView(
    modifier: Modifier = Modifier,
    selectedDay: CalendarDay = CalendarDay.create(),
    onSelectedDayChange: (CalendarDay) -> Unit = {},
    visibleMonth: CalendarDay = CalendarDay.create(),
    onVisibleMonthChange: (CalendarDay) -> Unit = {},
    today: CalendarDay = CalendarDay.create(),
    events: Set<CalendarDay> = emptySet()
) {

realdadfish

val configuration = project.configurations.getByName("prodConsumerReleaseRuntimeClasspath")
val artifactType = Attribute.of("artifactType", String::class.java)
// Some plugin can only work with configurations, while the Android Gradle Plugin (AGP) has the newer "artifact view"
// paradigm implemented. This makes it impossible to resolve most of the created, variant-aware
// configurations from AGP "by hand" without getting unmatched attribute exceptions.
// We now pick one artifact that holds our dependencies and add a custom compatibility rule
// for it which basically accepts all incoming compatibility issues as long as the produced value
// on "the other side" is a JAR or AAR artifact.
configuration.attributes {
  attribute(artifactType, "android-classes-directory")

ygrenzinger

Summary of book "Clean Architecture" by Robert C. Martin

Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software.

Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book.

Clean Architecture leaves me with the same feeling, even if it's pushing the development world to do better, has some good stories and present robust principles to build software.

The book is build around 34 chapters organised in chapters.

kaeawc

codecov:
  branch: master
  bot: null

coverage:
  precision: 2
  round: down
  range: "70...100"

  status:

apvasanth03

package com.vm.trinity.common.ui;

import android.annotation.TargetApi;
import android.graphics.Canvas;
import android.graphics.pdf.PdfDocument;
import android.os.AsyncTask;
import android.os.Build;
import android.util.Log;
import android.view.View;