mitzen

This is a good model and really fast too. Using the smaller size Q4_K_M and found out that it this version does not know how to call tool compare to its larger version empero-ai/Qwen3.8-4B-Distill-GGUF Switching to the Q_8 version aint any better. It still does not know how to call tools - the context given is way larger about 32k.  Then switching BF16 gives a context of 26.9k which is good but still unable to make any tool calling

Loving this model, it is really good and able to do coding, perform web search and use edit tool to generate the necessary code. For example, if you ask it to write a hello world app in android, all these file are generated.  Really happy with it - it is fast and really usable. It does have a context of 11.5k for me which hopefully I can crank it up. 

The default path for unsloth studio path unsloth\studio\sandbox . For my case that will be :-  C:\Users\nzai\.unsloth\studio\sandbox\__LOCALID_ZQvj3Mq\android-app 

Terraform tomap function requires the object to have the same schema otherwise it will give you the following error  │   on main.tf line 14, in resource "null_resource" "from_yaml_files": │   14:   for_each = tomap(local.yaml_data) │     ├──────────────── │     │ while calling tomap(v) │     │ local.yaml_data is object with 3 attributes │ │ Invalid value for "v" parameter: cannot convert object to map of any single type. Let's see what that looks like in yaml - if you're loading 3 files and all of them have the following - that's great! happy days. But if you have somehing that looks different  --- name : DisabledApp version : 0.5 enabled : false environment : development items :   - id : 1     type : test     name : test-service     port : 7000 different like this --- name : DisabledApp version : 0.5 enabled : false environment : development items :   - id : 1 ...

terraform "for" is used for data transformation while for_each is used to create resource for_each  locals {   servers = {     "web-1" = { cpu = 2 }     "web-2" = { cpu = 4 }   } } resource "null_resource" "servers" {   for_each = local . servers   # Creates 2 resources   triggers = { cpu = each . value . cpu } } for loop usage can be seen here locals {   names = [ "alice" , "bob" , "charlie" ]     # Transform to uppercase (just data)   upper_names = [ for name in local . names : upper (name)]     # Create map (just data)   name_map = { for name in local . names : name => upper (name)}     # Filter (just data)   short_names = [ for name in local . names : name if length (name) < 5 ] } output "result" {   value = local . upper_names   # Just prints ["ALICE", "BOB", "CHARLIE"] } Both for_each and for can be used ...

Bump into this error while trying to run my python code that requires some openai evaluation modules. from openai . types . evals . create_eval_jsonl_run_data_source_param import CreateEvalJSONLRunDataSourceParam , SourceFileID from openai . types . eval_create_params import DataSourceConfigCustom from azure . identity import DefaultAzureCredential from azure . ai . projects import AIProjectClient  Then when I checked my vscode python interpreter, I noticed that my setup wasn't quite right, I had to go back to my .venv folder and start up my vscode from there. Then it was able to resolve the python modules.

We can use multiple approach to query a logs in cloudwatch - log analytics. 1. Logs Insights QL (the native language)   Example of query would look similiar to this  SOURCE logGroups ( namePrefix : [], class : "STANDARD" ) START =- 3600s END = 0s | fields @timestamp , @message | filter @message like /Error/ | sort @timestamp desc | limit 10000 2. OpenSearch Structured Query Language (SQL)  For teams that prefer industry-standard database syntax, CloudWatch supports OpenSearch SQL. It is highly useful if you need to perform relational actions like JOIN commands across logs. SOURCE "arn:aws:logs:ap-southeast-2:042005083034:log-group:/aws/lambda/my-function" START =- 3600s END = 0s | SELECT status , COUNT ( * ) FROM log_group_name 3. OpenSearch Piped Processing Language (PPL) OpenSearch PPL is an alternative pipeline-based query language. It allows you to process data sequentially through a series of chained commands.  SOURCE "arn:aws:logs:a...

Understanding otel collector and how it works is important for us to configure and push relevant metrics over. The focus of this article is to provide a simple sraight forward configurations. There are more complex setup available, we will cover those later.  This is an example of the OTEL architecture  Receiver First we have the " Receiver " - where data comes in. In this setup, data can be pushed via port 4318 (over http) and 4317 (over gRPC). # collector-config.yaml receivers :   otlp :     protocols :       grpc :         endpoint : 0.0.0.0:4317       http :         endpoint : 0.0.0.0:4318 Exporter  Here we have configure our otel collector to log metric to console (debug) and prometheus on port 8888. So we are exposing a new promethus service here and any prometheus services (if configured correctly) would be able to scrap these out. The endpoint exposed is /metrics exporters : ...

In this example, we will be pushing or in better term exporting metric to our otel-collector. Generally there are a couple of approach for otel collector to obtain metrics data 1. push - this is where application push metric data to it  2. pull - this is where it scrap for metrics  3. others In this example, we will be setting up for scenario 1 - where app will push metrics. Let's setup our otel collector first Here is our config. # collector-config.yaml receivers :   otlp :     protocols :       grpc :         endpoint : 0.0.0.0:4317       http :         endpoint : 0.0.0.0:4318 exporters :   debug :     verbosity : detailed service :   pipelines :     traces :       receivers : [ otlp ]       exporters : [ debug ]     metrics :       receivers : [ otlp ]       exporters : [ debug ]   ...